From d52d850b8bb1b811a0395e184fc7dd26bf7693b6 Mon Sep 17 00:00:00 2001 From: Crypto2099 <63186174+Crypto2099@users.noreply.github.com> Date: Thu, 6 Jul 2023 07:20:04 -0700 Subject: [PATCH 01/54] CIP-????: POO Protocol Initial Commit/PR --- CIP-0013/README.md | 139 +++++++++++++++++--- CIP-XXXX/README.md | 315 +++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 434 insertions(+), 20 deletions(-) create mode 100644 CIP-XXXX/README.md diff --git a/CIP-0013/README.md b/CIP-0013/README.md index 9cf1892617..7e005faebc 100644 --- a/CIP-0013/README.md +++ b/CIP-0013/README.md @@ -4,24 +4,25 @@ Title: Cardano URI Scheme Status: Proposed Category: Wallets Authors: - - Sebastien Guillemot - - Vicente Almonacid - - Robert Phair +- Sebastien Guillemot +- Vicente Almonacid +- Robert Phair +- Adam Dean Implementors: N/A Discussions: - - https://github.com/Emurgo/EmIPs/pull/2 - - https://forum.cardano.org/t/cip-cardano-payment-uri-scheme/41457 - - https://github.com/cardano-foundation/CIPs/pull/25 - - https://github.com/cardano-foundation/CIPs/pull/61 - - https://github.com/cardano-foundation/CIPs/pull/86 - - https://forum.cardano.org/t/cip-stake-uri-scheme-for-pools-delegation-portfolios/40594 +- https://github.com/Emurgo/EmIPs/pull/2 +- https://forum.cardano.org/t/cip-cardano-payment-uri-scheme/41457 +- https://github.com/cardano-foundation/CIPs/pull/25 +- https://github.com/cardano-foundation/CIPs/pull/61 +- https://github.com/cardano-foundation/CIPs/pull/86 +- https://forum.cardano.org/t/cip-stake-uri-scheme-for-pools-delegation-portfolios/40594 Created: 2020-09-22 License: CC-BY-4.0 --- ## Abstract -This proposal describes a basic URI scheme to handle Ada transfers and links to single stake pools or weighted lists of multiple pools. +This proposal describes a basic URI scheme to handle ADA transfers and links to single stake pools or weighted lists of multiple pools. ## Motivation: why is this CIP necessary? @@ -45,6 +46,19 @@ Pool links allow for interfaces to initiate delegation transactions without requ URIs for weighted stake pool lists provide alternatives to using a JSON file to implement *delegation portfolios* in a way that may better suit certain platforms, applications, or social contexts. +### For Token Claim URIs: + +Distributing Native Assets (and/or ADA) to attendees of IRL events has historically been a pain point in the ecosystem. +Some implemented solutions have included: Pre-generating wallet seed phrases and pre-populating these wallets with a +minimum amount of ADA as well as the desired Native Assets, (re)creating token fountain/faucet designs which can be +cumbersome and not user-friendly to instruct individuals to install a wallet, visit a website, enter a code and claim +tokens. + +The Cardano Token Claim URI schema is proposed to allow wallets (particularly mobile wallets) to implement a QR-friendly +URI structure allowing for easy onboarding and distribution of Native Assets and/or ADA to individuals in a variety of +situations but not least of which being at IRL events specifically tailored and geared to onboarding new users to the +ecosystem. + ## Specification The core implementation should follow the [BIP-21](https://github.com/bitcoin/bips/blob/master/bip-0021.mediawiki) standard (with `bitcoin:` replaced with `web+cardano:`) @@ -54,11 +68,19 @@ Rationale: - Many wallets support multiple currencies. Following the same standard will ensure higher adoption of our protocol. Examples: -``` +```html + Donate + + Stake with us Split between our 2 related pools Choose our least saturated pool + + +Claim $HOSKY +Claim $HOSKY +Claim NFTxLV Commermorative NFT! ``` ### Considerations @@ -73,11 +95,12 @@ This is an initial, simplified protocol definition for fast implementation; it o * for a payment URI (authority unspecified), an address and an optional amount parameter; * for a stake pool URI (authority = `stake`), a weighted list of one or more stake pools. +* for a token claim URI (authority = `claim`), a versioning path, a `faucet_url` and an optional `code` (required in v1). As discussed above, these rules are likely to evolve in order to support other capabilities of the Cardano blockchain. ``` -cardanourn = "web+cardano:" (paymentref | stakepoolref) +cardanourn = "web+cardano:" (paymentref | stakepoolref | claimtokenref) paymentref = cardanoaddress [ "?" amountparam ] cardanoaddress = *(base58 | bech32) @@ -92,12 +115,18 @@ poolhexid = 56HEXDIG poolticker = 3*5UNICODE proportion = *digit [ "." *digit ] + +claimtokenref = "//claim" claimversion claimquery +claimversion = "/v1" | "/v2" +claimquery = ( "?" claimurl) ?( "&" claimcode) +claimurl = "faucet_url=" text +claimcode = "code=" text ``` For grammar reference, see: - - [Wikipedia > Augmented Backus–Naur form](https://en.wikipedia.org/wiki/Augmented_Backus%E2%80%93Naur_form) - - [Unicode in ABNF](https://tools.ietf.org/html/draft-seantek-unicode-in-abnf-00) +- [Wikipedia > Augmented Backus–Naur form](https://en.wikipedia.org/wiki/Augmented_Backus%E2%80%93Naur_form) +- [Unicode in ABNF](https://tools.ietf.org/html/draft-seantek-unicode-in-abnf-00) #### Payment URI queries @@ -116,6 +145,22 @@ When there is more than one pool registered with any of the specified `poolticke * Any missing `proportion` is assigned a precise value of `1`. * If a stake pool is listed multiple times, the URI is rejected as invalid. +#### Token Claim URI queries + +Token Claim URIs must include a path indicating protocol version and at minimum a `faucet_url` argument pointing to the +faucet hosted and maintained by the project. + +**All arguments for Token Claim URIs should be URL-encoded** + +***Version 1 URIs*** + +Version 1 URIs must include a `faucet_url` and a `code` as required parameters. + +***Version 2 URIs*** + +Version 2 URIs must include a `faucet_url` and may optionally include a `code` or other arguments per the needs of the +project's faucet API. + ### Handling stake pool links The wallet UI should always confirm the exact delegation choice even when it is unambiguous from the URI. When the user has multiple wallets, the wallet UI must select which wallet(s) the user will be delegating from. @@ -125,11 +170,59 @@ If, during a wallet or other application's development process, it is still only * any value for the first URI query argument; * any URI query argument beyond the first. +### Handling Token Claim URI queries + +The token claim URI should consist of a required versioning `path` (i.e. `/v1` or `/v2`) as well as one or more required +or optional URL-encoded arguments. + +All Token Claim URIs must include a URL-encoded `faucet_url` argument. The `code` argument is required for Version 1 +Claim URIs while being flagged as optional for Version 2 and beyond. + +The wallet provider should send a POST request to the provided `Faucet URL` that includes: +* The change/receipt wallet address of the user +* Any additional arguments specified in the URI as key: value pairs + +**Example:** + +``` +URI: web+cardano://claim/v1?faucet_url=https%3A%2F%2Fclaim.hosky.io%2Fconsensus23&code=ABC123 +Version: 1 +URL: https://claim.hosky.io/consensus23 +CODE: ABC123 +JSON POST Data: +``` +```json +{ + "address": "addr1abc...xyz", + "code": "ABC123" +} +``` + +Faucet implementations should follow a well-documented API standard to be detailed in a separate CIP document. +[API Standard Documentation](https://app.swaggerhub.com/apis/CatastrophicCardano/FaucetAPI/1) (OpenAPI) + +#### Note on the `address` field + +The wallet should always send the recipient address in bech32 format. If a particular token faucet implementation wishes +to restrict or limit access to their faucet based on staking key or individual wallet address, this should be handled at +the wallet end. + +#### Note on the `code` field + +The code is required in Version 1 but specified as optional in Version 2 and beyond. Specifying a `code` allows for +reliable tracking and/or limiting of claims to the faucet host. Codes can be used to identify attendees of particular +events (i.e. CODE = `consensus2023`) or can be a unique, one-time code per user (i.e. CODE = `abc123xyz987`). In this +way we leave the code to be flexible to match a variety of analytical use cases depending upon the needs of the +implementing project. + ### Security Considerations 1. For payment links, we cannot prompt the user to send the funds right away as they may not be fully aware of the URI they clicked or were redirected to. Instead, it may be better to simply pre-populate fields in a transaction. 2. For either payment or staking links, we should be wary of people who disguise links as actually opening up a phishing website that LOOKS like that corresponding part of the wallet UI. 3. If wallets *create* stake pool links, the actual ada or lovelace balance should not be used literally as the `proportion` figure, to avoid revealing the identity of the wallet owner who is creating the portfolio (e.g. the proportions could be scaled to normalise the largest to `1`). +4. Wallets should prompt/warn users prior to sending potentially sensitive information (wallet address + code) via the + token claim URI. An informational pop-up or confirmation modal should be displayed to users such as: + `We are about to send your address and code 123456 to https://claim.hosky.io. Are you sure you want to proceed?` ## Rationale: how does this CIP achieve its goals? @@ -139,9 +232,9 @@ An alternative solution to the original problem described above is to use standa For background, see - - [Android Developer Docs > Add intent filters for incoming links](https://developer.android.com/training/app-links/deep-linking#adding-filters) - - [Apple Developer Docs > Defining a custom URL scheme for your app](https://developer.apple.com/documentation/xcode/defining-a-custom-url-scheme-for-your-app) - - [React Native > Linking](https://reactnative.dev/docs/linking.html) +- [Android Developer Docs > Add intent filters for incoming links](https://developer.android.com/training/app-links/deep-linking#adding-filters) +- [Apple Developer Docs > Defining a custom URL scheme for your app](https://developer.apple.com/documentation/xcode/defining-a-custom-url-scheme-for-your-app) +- [React Native > Linking](https://reactnative.dev/docs/linking.html) ### How URI delegation portfolio links supplement use of JSON files for the same purpose? @@ -156,9 +249,14 @@ For a CIP based on this principle, see [CIP-0017](https://github.com/cardano-fou ### Acceptance Criteria - [x] There exist one or more wallets supporting Payment URIs. - - [x] Yoroi + - [x] Yoroi - [x] There exist one or more wallets supporting Stake Pool URIs. - - [ ] TBD + - [ ] TBD +- [X] There exists one or more wallets supporting Token Claim URIs. + - Version 1 + - [X] VESPR + - Version 2 + - [ ] VESPR ### Implementation Plan @@ -166,6 +264,7 @@ Survey contemporary wallet developers to suggest adoption of both feature sets, - Payment URIs - Stake Pool URIs +- Token Claim URIs This survey can be conducted and/or advocated by either (ideally both): @@ -174,4 +273,4 @@ This survey can be conducted and/or advocated by either (ideally both): ## Copyright -This CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode). +This CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode). \ No newline at end of file diff --git a/CIP-XXXX/README.md b/CIP-XXXX/README.md new file mode 100644 index 0000000000..763f0091cf --- /dev/null +++ b/CIP-XXXX/README.md @@ -0,0 +1,315 @@ +--- +CIP: CIP-???? +Title: POO (Proof of Onboarding) Protocol +Status: Proposed +Category: Wallets +Authors: +- Adam Dean +- Carl +- Alex Dochioiu + Implementors: +- VESPR Wallet + Discussions: +- https://github.com/cardano-foundation/CIPs/pull/ + Created: 2023-06-20 + License: CC-BY-4.0 +--- + +# Abstract + +Since at least 2021 when Cardano entered the Mary Era and implemented Native Assets, projects and creators building on +the network have sought a means to distribute their tokens efficiently to users. Of particular frustration has been the +ability to onboard new users at real-world events. Solutions for this historically have been to create and preload +"paper wallets" where a seed phrase and accompanying password is generated by the project, pre-populated with tokens and +ADA, and then delivered over to attendees of said event. + +The creation of this addendum to the CIP-13 Cardano URI scheme seeks to minimize this friction and take advantage of +existing technology to enable a new era of user onboarding, particularly at real world events through the use of a +defined URI scheme enabling instant and frictionless communication between a project's "token fountain" and the user's +wallet to reward, incentivize, and onboard new users easier than ever. + +This CIP defines an extension to the CIP-13 URI Scheme as well as an API specification to facilitate and streamline +communications between wallets and project servers. + +# Motivation: Why is this CIP necessary? + +By leveraging the power of Cardano-specific URIs (CIP-13) and the modern technological advances of mobile devices and +wallets we can provide a framework for Cardano projects to attend real world events, incentivize or reward attendees via +their Native Assets, and have facts and figures to help support and analyze the impact that their attendance had (Proof +of Onboarding). + +Furthermore, the aforementioned "paper wallet" technique has many drawbacks including: +* The person(s) responsible for generating the paper wallets at some point have access to the seed phrases generated, leading to a potential security vulnerability +* Projects would need to preload these wallets with funds/tokens; this makes it difficult and/or impossible to reliably know how many of the paper wallets were ever actually claimed +* For those wallets that go forever unclaimed, this essentially creates a permanent "burn" of both Lovelace and the native assets of the project; less than ideal + +We feel that this is necessary as a CIP in order to minimize friction for new projects while maximizing compatibility +across the wide spectrum of Cardano wallets. + +# Specification + +Additional specifications for this CIP relevant to CIP-13 have been made under the heading of "Token Claim URI" under +its [README.md](../CIP-0013/README.md) + +## Process Flow + +The envisioned process flow for the POO Protocol is as follows: +1. The project set asides some amount of budget (tokens + Lovelace [minUTxO]) for a given marketing push or IRL event +2. If desired, one or more `codes` are generated to help track and analyze claiming figures +3. QR Code(s) may be generated, printed, and otherwise displayed or given to users during the course of events +4. Users scan the code with their mobile light wallet +5. The light wallet makes a POST request to the API endpoint specified in the Cardano URI containing the user's wallet address and the included code (if present) +6. The project API returns a documented status code indicating the success or failure of the operation +7. If a successful status is detected and returned, the project issues tokens to the specified address per their campaign settings + +## URI Format + +The URI format consists of the CIP-13 `web+cardano://` scheme, followed by the `claim` authority, then a `version` path. + +***NOTE: ALL ARGUMENTS SHOULD BE URL-ENCODED*** + +### Version 1 + +Version 1 URIs must include `/v1` as the path of the URI. + +Version 1 URIs must include two required arguments: + +* `faucet_url` as a fully-typed URL (i.e. https://claim.hosky.io) +* `code` as either a campaign identifier or unique, one-time use code + +_Version 1 Examples:_ + +```html + +Thanks for attending Consensus 2023! + + +Claim your $HOSKY now! +``` + +### Version 2 + +Version 2 URIs must include `/v2` as the path of the URI + +Version 2 URIs must include one required argument: + +* `faucet_url` as a fully-typed URL (i.e. https://claim.hosky.io) + +Version 2 URIs may include additional, optional arguments: + +* `code` as either a campaign identifier or unique, one-time use code +* Additional arguments should be passed by the wallet to the API server in the JSON body of the POST request. + + +_Version 2 Examples:_ +```html + +Claim $HOSKY Now! + + +Claim your NFTxLV 2023 NFT now! + + +Claim Some $HOSKY! + + +Get your $HOSKY! +``` + +## Wallet Requests + +Light wallets that detect and support `web+cardano` URIs as well as mobile wallets who detect either a QR code or other +link with this format should parse the URI and send a `POST` request to the specified URL containing a JSON payload +including: + +* The user's wallet receive address +* The code (if present in the URI [required for Version 1]) + +_Examples:_ +```json +URI: web+cardano://claim/v1?faucet_url=https%3A%2F%2Fclaim.hosky.io +URL: https://claim.hosky.io +POST JSON Data: +{ + "address": "addr1abc...xyz" +} + +URI: web+cardano://claim/v1?faucet_url=https%3A%2F%2Fclaim.nftxlv.com&code=NFTxLV2023 +URL: https://claim.nftxlv.com +JSON POST Data: +{ + "address": "addr1abc...xyz", + "code": "NFTxLV2023" +} + +URI: web+cardano://claim/v1?faucet_url=https%3A%2F%2Fclaim.hosky.io&code=ABC123 +URL: https://claim.hosky.io +POST JSON Data: +{ + "address": "addr1abc...xyz", + "code": "ABC123" +} + +URI: web+cardano://claim/v2?faucet_url=https%3A%2F%2Fclaim.nftxlv.com&code=NFTxLV2023&user_id=Adam1337 +URL: https://claim.nftxlv.com +POST JSON Data: +{ + "address": "addr1abc...xyz", + "code": "NFTxLV2023", + "user_id": "Adam1337" +} +``` + +## API Server Response Codes + +The API server is expected to return one of the following defined status blocks in `application/json` format. Any other +responses from the API server should be considered invalid and discarded or display an error. + +The expected API that any token fountain implementation should follow and wallet integrators should expect is documented +on Swagger! + +* [Version 1](https://app.swaggerhub.com/apis/CatastrophicCardano/FaucetAPI/1) +* [Version 2](https://app.swaggerhub.com/apis/CatastrophicCardano/FaucetAPI/2) + +### Successful Responses + +#### Valid (200) + +First Successful Request + +```json +{ + "code": 200, + "lovelaces": "2000000", + "queue_position": 23, + "status": "accepted", + "tokens": { + "a0028f350aaabe0545fdcb56b039bfb08e4bb4d8c4d7c3c7d481c235.HOSKY": "29433292000000" + } +} +``` + +#### Valid Queued (201) + +Subsequent Successful Request (Address + Code Match) prior to token distribution + +```json +{ + "code": 201, + "lovelaces": "2000000", + "queue_position": 1, + "status": "queued", + "tokens": { + "a0028f350aaabe0545fdcb56b039bfb08e4bb4d8c4d7c3c7d481c235.HOSKY": "29433292000000" + } +} +``` + +#### Valid Complete (202) + +Subsequent Successful Request (Address + Code Match) after token(s) are distributed + +```json +{ + "code": 202, + "lovelaces": "2000000", + "status": "claimed", + "tokens": { + "a0028f350aaabe0545fdcb56b039bfb08e4bb4d8c4d7c3c7d481c235.HOSKY": "29433292000000" + }, + "tx_hash": "TX1234" +} +``` + +### Error Responses + +#### Invalid - Not Known (404) + +The specified code does not exist + +```json +{ + "code": 404, + "status": "notfound" +} +``` + +#### Invalid - Already Claimed (409) + +An address was already used (if not code present) or the code presented was found but the address did not match + +```json +{ + "code": 409, + "status": "alreadyclaimed" +} +``` + +#### Invalid - Expired (410) + +For time-limited fountains, a code of 410 means that the period for redemption has expired + +```json +{ + "code": 410, + "status": "expired" +} +``` + +#### Invalid - Too Early (425) + +For time-limited fountains, a code of 425 means that the period for redemption has not begun yet + +```json +{ + "code": 425, + "status": "tooearly" +} +``` + +#### Invalid - Rate Limited (429) + +Rate limiting settings and details are left to the discretion and implementation of individual projects. A status code +of 429 or this status response should be considered as a rate limiting response. + +```json +{ + "code": 429, + "status": "ratelimited" +} +``` + +#### Server Error (500) + +Implementations should of course be prepared to handle situations where a server is non-responsive for any reason and +be prepared to handle any other, non-specified error codes including 500 codes. + +# Rationale + +By creating a well-defined standard for both a CIP-13 URI scheme and the expected API response(s) we can create a +framework that both wallets and projects can utilize to encourage and onboard new users into the ecosystem via Native +Asset incentive models without needlessly and constantly reinventing the wheel for each product or project. + +By utilizing this framework, projects can have accurate, measurable analytics into the success of various real-world +marketing and event efforts: Proof of Onboarding. + +# Path to Active + +## Acceptance Criteria + +- [ ] Demonstrate a working MVP +- [ ] Open source an MVP example of token faucet server-side code +- [ ] Receive feedback and iterate on Version 2 based on community feedback + +## Implementation Plan + +In order to encourage adoption of this standard the authors commit to execute a functional a minimum viable product +proof of concept demonstration in partnership between Adam Dean, HOSKY Token, and VESPR wallet. This real-world +implementation should give us important insight on whether the system requires additional modifications or changes. + +From there we will do our best to engage with other teams and projects in the ecosystem to encourage and support +adoption of this standard on a larger scale. + +# Copyright + +This CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode). \ No newline at end of file From 11b4b5a41e8d02f2dccacd3180c454d7eba43565 Mon Sep 17 00:00:00 2001 From: Crypto2099 <63186174+Crypto2099@users.noreply.github.com> Date: Thu, 6 Jul 2023 07:39:02 -0700 Subject: [PATCH 02/54] Update with relevant links to the PR --- CIP-0013/README.md | 1 + CIP-XXXX/README.md | 2 +- 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/CIP-0013/README.md b/CIP-0013/README.md index 7e005faebc..0de956aa67 100644 --- a/CIP-0013/README.md +++ b/CIP-0013/README.md @@ -16,6 +16,7 @@ Discussions: - https://github.com/cardano-foundation/CIPs/pull/61 - https://github.com/cardano-foundation/CIPs/pull/86 - https://forum.cardano.org/t/cip-stake-uri-scheme-for-pools-delegation-portfolios/40594 +- https://github.com/cardano-foundation/CIPs/pull/546 Created: 2020-09-22 License: CC-BY-4.0 --- diff --git a/CIP-XXXX/README.md b/CIP-XXXX/README.md index 763f0091cf..b9471ac22c 100644 --- a/CIP-XXXX/README.md +++ b/CIP-XXXX/README.md @@ -10,7 +10,7 @@ Authors: Implementors: - VESPR Wallet Discussions: -- https://github.com/cardano-foundation/CIPs/pull/ +- https://github.com/cardano-foundation/CIPs/pull/546 Created: 2023-06-20 License: CC-BY-4.0 --- From 5c5b0e49d0b241c36034c5f67eb992db75d44973 Mon Sep 17 00:00:00 2001 From: Crypto2099 <63186174+Crypto2099@users.noreply.github.com> Date: Thu, 6 Jul 2023 08:44:41 -0700 Subject: [PATCH 03/54] Fix YAML format --- CIP-XXXX/README.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/CIP-XXXX/README.md b/CIP-XXXX/README.md index b9471ac22c..c596522996 100644 --- a/CIP-XXXX/README.md +++ b/CIP-XXXX/README.md @@ -7,9 +7,9 @@ Authors: - Adam Dean - Carl - Alex Dochioiu - Implementors: +Implementors: - VESPR Wallet - Discussions: +Discussions: - https://github.com/cardano-foundation/CIPs/pull/546 Created: 2023-06-20 License: CC-BY-4.0 From 5a62c5bb3602f9937a7d9150ec8d056e2d86f880 Mon Sep 17 00:00:00 2001 From: Crypto2099 <63186174+Crypto2099@users.noreply.github.com> Date: Thu, 6 Jul 2023 08:45:10 -0700 Subject: [PATCH 04/54] Fix YAML format --- CIP-XXXX/README.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/CIP-XXXX/README.md b/CIP-XXXX/README.md index c596522996..88cd3eee98 100644 --- a/CIP-XXXX/README.md +++ b/CIP-XXXX/README.md @@ -11,8 +11,8 @@ Implementors: - VESPR Wallet Discussions: - https://github.com/cardano-foundation/CIPs/pull/546 - Created: 2023-06-20 - License: CC-BY-4.0 +Created: 2023-06-20 +License: CC-BY-4.0 --- # Abstract From 686dcf5c60f910e7c75b49f66e612c6a08870cff Mon Sep 17 00:00:00 2001 From: Crypto2099 <63186174+Crypto2099@users.noreply.github.com> Date: Tue, 18 Jul 2023 08:10:35 -0700 Subject: [PATCH 05/54] Rollback changes to the CIP-13 README.md and add to the Proof of Onboarding README.md and update name and other clarifications per feedback. Also fixed in-file JSON errors that were causing problems. --- CIP-0013/README.md | 140 +++++++------------------------------------- CIP-XXXX/README.md | 143 ++++++++++++++++++++++++++++++++++++++++----- 2 files changed, 148 insertions(+), 135 deletions(-) diff --git a/CIP-0013/README.md b/CIP-0013/README.md index 0de956aa67..9cf1892617 100644 --- a/CIP-0013/README.md +++ b/CIP-0013/README.md @@ -4,26 +4,24 @@ Title: Cardano URI Scheme Status: Proposed Category: Wallets Authors: -- Sebastien Guillemot -- Vicente Almonacid -- Robert Phair -- Adam Dean + - Sebastien Guillemot + - Vicente Almonacid + - Robert Phair Implementors: N/A Discussions: -- https://github.com/Emurgo/EmIPs/pull/2 -- https://forum.cardano.org/t/cip-cardano-payment-uri-scheme/41457 -- https://github.com/cardano-foundation/CIPs/pull/25 -- https://github.com/cardano-foundation/CIPs/pull/61 -- https://github.com/cardano-foundation/CIPs/pull/86 -- https://forum.cardano.org/t/cip-stake-uri-scheme-for-pools-delegation-portfolios/40594 -- https://github.com/cardano-foundation/CIPs/pull/546 + - https://github.com/Emurgo/EmIPs/pull/2 + - https://forum.cardano.org/t/cip-cardano-payment-uri-scheme/41457 + - https://github.com/cardano-foundation/CIPs/pull/25 + - https://github.com/cardano-foundation/CIPs/pull/61 + - https://github.com/cardano-foundation/CIPs/pull/86 + - https://forum.cardano.org/t/cip-stake-uri-scheme-for-pools-delegation-portfolios/40594 Created: 2020-09-22 License: CC-BY-4.0 --- ## Abstract -This proposal describes a basic URI scheme to handle ADA transfers and links to single stake pools or weighted lists of multiple pools. +This proposal describes a basic URI scheme to handle Ada transfers and links to single stake pools or weighted lists of multiple pools. ## Motivation: why is this CIP necessary? @@ -47,19 +45,6 @@ Pool links allow for interfaces to initiate delegation transactions without requ URIs for weighted stake pool lists provide alternatives to using a JSON file to implement *delegation portfolios* in a way that may better suit certain platforms, applications, or social contexts. -### For Token Claim URIs: - -Distributing Native Assets (and/or ADA) to attendees of IRL events has historically been a pain point in the ecosystem. -Some implemented solutions have included: Pre-generating wallet seed phrases and pre-populating these wallets with a -minimum amount of ADA as well as the desired Native Assets, (re)creating token fountain/faucet designs which can be -cumbersome and not user-friendly to instruct individuals to install a wallet, visit a website, enter a code and claim -tokens. - -The Cardano Token Claim URI schema is proposed to allow wallets (particularly mobile wallets) to implement a QR-friendly -URI structure allowing for easy onboarding and distribution of Native Assets and/or ADA to individuals in a variety of -situations but not least of which being at IRL events specifically tailored and geared to onboarding new users to the -ecosystem. - ## Specification The core implementation should follow the [BIP-21](https://github.com/bitcoin/bips/blob/master/bip-0021.mediawiki) standard (with `bitcoin:` replaced with `web+cardano:`) @@ -69,19 +54,11 @@ Rationale: - Many wallets support multiple currencies. Following the same standard will ensure higher adoption of our protocol. Examples: -```html - +``` Donate - - Stake with us Split between our 2 related pools Choose our least saturated pool - - -Claim $HOSKY -Claim $HOSKY -Claim NFTxLV Commermorative NFT! ``` ### Considerations @@ -96,12 +73,11 @@ This is an initial, simplified protocol definition for fast implementation; it o * for a payment URI (authority unspecified), an address and an optional amount parameter; * for a stake pool URI (authority = `stake`), a weighted list of one or more stake pools. -* for a token claim URI (authority = `claim`), a versioning path, a `faucet_url` and an optional `code` (required in v1). As discussed above, these rules are likely to evolve in order to support other capabilities of the Cardano blockchain. ``` -cardanourn = "web+cardano:" (paymentref | stakepoolref | claimtokenref) +cardanourn = "web+cardano:" (paymentref | stakepoolref) paymentref = cardanoaddress [ "?" amountparam ] cardanoaddress = *(base58 | bech32) @@ -116,18 +92,12 @@ poolhexid = 56HEXDIG poolticker = 3*5UNICODE proportion = *digit [ "." *digit ] - -claimtokenref = "//claim" claimversion claimquery -claimversion = "/v1" | "/v2" -claimquery = ( "?" claimurl) ?( "&" claimcode) -claimurl = "faucet_url=" text -claimcode = "code=" text ``` For grammar reference, see: -- [Wikipedia > Augmented Backus–Naur form](https://en.wikipedia.org/wiki/Augmented_Backus%E2%80%93Naur_form) -- [Unicode in ABNF](https://tools.ietf.org/html/draft-seantek-unicode-in-abnf-00) + - [Wikipedia > Augmented Backus–Naur form](https://en.wikipedia.org/wiki/Augmented_Backus%E2%80%93Naur_form) + - [Unicode in ABNF](https://tools.ietf.org/html/draft-seantek-unicode-in-abnf-00) #### Payment URI queries @@ -146,22 +116,6 @@ When there is more than one pool registered with any of the specified `poolticke * Any missing `proportion` is assigned a precise value of `1`. * If a stake pool is listed multiple times, the URI is rejected as invalid. -#### Token Claim URI queries - -Token Claim URIs must include a path indicating protocol version and at minimum a `faucet_url` argument pointing to the -faucet hosted and maintained by the project. - -**All arguments for Token Claim URIs should be URL-encoded** - -***Version 1 URIs*** - -Version 1 URIs must include a `faucet_url` and a `code` as required parameters. - -***Version 2 URIs*** - -Version 2 URIs must include a `faucet_url` and may optionally include a `code` or other arguments per the needs of the -project's faucet API. - ### Handling stake pool links The wallet UI should always confirm the exact delegation choice even when it is unambiguous from the URI. When the user has multiple wallets, the wallet UI must select which wallet(s) the user will be delegating from. @@ -171,59 +125,11 @@ If, during a wallet or other application's development process, it is still only * any value for the first URI query argument; * any URI query argument beyond the first. -### Handling Token Claim URI queries - -The token claim URI should consist of a required versioning `path` (i.e. `/v1` or `/v2`) as well as one or more required -or optional URL-encoded arguments. - -All Token Claim URIs must include a URL-encoded `faucet_url` argument. The `code` argument is required for Version 1 -Claim URIs while being flagged as optional for Version 2 and beyond. - -The wallet provider should send a POST request to the provided `Faucet URL` that includes: -* The change/receipt wallet address of the user -* Any additional arguments specified in the URI as key: value pairs - -**Example:** - -``` -URI: web+cardano://claim/v1?faucet_url=https%3A%2F%2Fclaim.hosky.io%2Fconsensus23&code=ABC123 -Version: 1 -URL: https://claim.hosky.io/consensus23 -CODE: ABC123 -JSON POST Data: -``` -```json -{ - "address": "addr1abc...xyz", - "code": "ABC123" -} -``` - -Faucet implementations should follow a well-documented API standard to be detailed in a separate CIP document. -[API Standard Documentation](https://app.swaggerhub.com/apis/CatastrophicCardano/FaucetAPI/1) (OpenAPI) - -#### Note on the `address` field - -The wallet should always send the recipient address in bech32 format. If a particular token faucet implementation wishes -to restrict or limit access to their faucet based on staking key or individual wallet address, this should be handled at -the wallet end. - -#### Note on the `code` field - -The code is required in Version 1 but specified as optional in Version 2 and beyond. Specifying a `code` allows for -reliable tracking and/or limiting of claims to the faucet host. Codes can be used to identify attendees of particular -events (i.e. CODE = `consensus2023`) or can be a unique, one-time code per user (i.e. CODE = `abc123xyz987`). In this -way we leave the code to be flexible to match a variety of analytical use cases depending upon the needs of the -implementing project. - ### Security Considerations 1. For payment links, we cannot prompt the user to send the funds right away as they may not be fully aware of the URI they clicked or were redirected to. Instead, it may be better to simply pre-populate fields in a transaction. 2. For either payment or staking links, we should be wary of people who disguise links as actually opening up a phishing website that LOOKS like that corresponding part of the wallet UI. 3. If wallets *create* stake pool links, the actual ada or lovelace balance should not be used literally as the `proportion` figure, to avoid revealing the identity of the wallet owner who is creating the portfolio (e.g. the proportions could be scaled to normalise the largest to `1`). -4. Wallets should prompt/warn users prior to sending potentially sensitive information (wallet address + code) via the - token claim URI. An informational pop-up or confirmation modal should be displayed to users such as: - `We are about to send your address and code 123456 to https://claim.hosky.io. Are you sure you want to proceed?` ## Rationale: how does this CIP achieve its goals? @@ -233,9 +139,9 @@ An alternative solution to the original problem described above is to use standa For background, see -- [Android Developer Docs > Add intent filters for incoming links](https://developer.android.com/training/app-links/deep-linking#adding-filters) -- [Apple Developer Docs > Defining a custom URL scheme for your app](https://developer.apple.com/documentation/xcode/defining-a-custom-url-scheme-for-your-app) -- [React Native > Linking](https://reactnative.dev/docs/linking.html) + - [Android Developer Docs > Add intent filters for incoming links](https://developer.android.com/training/app-links/deep-linking#adding-filters) + - [Apple Developer Docs > Defining a custom URL scheme for your app](https://developer.apple.com/documentation/xcode/defining-a-custom-url-scheme-for-your-app) + - [React Native > Linking](https://reactnative.dev/docs/linking.html) ### How URI delegation portfolio links supplement use of JSON files for the same purpose? @@ -250,14 +156,9 @@ For a CIP based on this principle, see [CIP-0017](https://github.com/cardano-fou ### Acceptance Criteria - [x] There exist one or more wallets supporting Payment URIs. - - [x] Yoroi + - [x] Yoroi - [x] There exist one or more wallets supporting Stake Pool URIs. - - [ ] TBD -- [X] There exists one or more wallets supporting Token Claim URIs. - - Version 1 - - [X] VESPR - - Version 2 - - [ ] VESPR + - [ ] TBD ### Implementation Plan @@ -265,7 +166,6 @@ Survey contemporary wallet developers to suggest adoption of both feature sets, - Payment URIs - Stake Pool URIs -- Token Claim URIs This survey can be conducted and/or advocated by either (ideally both): @@ -274,4 +174,4 @@ This survey can be conducted and/or advocated by either (ideally both): ## Copyright -This CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode). \ No newline at end of file +This CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode). diff --git a/CIP-XXXX/README.md b/CIP-XXXX/README.md index 88cd3eee98..a3385c7e54 100644 --- a/CIP-XXXX/README.md +++ b/CIP-XXXX/README.md @@ -1,6 +1,6 @@ --- CIP: CIP-???? -Title: POO (Proof of Onboarding) Protocol +Title: Proof of Onboarding Status: Proposed Category: Wallets Authors: @@ -48,6 +48,108 @@ across the wide spectrum of Cardano wallets. # Specification +## CIP-13 Cardano URI Extensions + +Distributing Native Assets (and/or ADA) to attendees of IRL events has historically been a pain point in the ecosystem. +Some implemented solutions have included: Pre-generating wallet seed phrases and pre-populating these wallets with a +minimum amount of ADA as well as the desired Native Assets, (re)creating token fountain/faucet designs which can be +cumbersome and not user-friendly to instruct individuals to install a wallet, visit a website, enter a code and claim +tokens. + +The Cardano Token Claim URI schema is proposed to allow wallets (particularly mobile wallets) to implement a QR-friendly +URI structure allowing for easy onboarding and distribution of Native Assets and/or ADA to individuals in a variety of +situations but not least of which being at IRL events specifically tailored and geared to onboarding new users to the +ecosystem. + +Examples: +```html + +Claim $HOSKY +Claim $HOSKY +Claim NFTxLV Commermorative NFT! +``` + +### ABNF Grammar + +* For a token claim URI (authority = `claim`), a versioning path, a `faucet_url` and an optional `code` (required in v1). + +``` +cardanourn = "web+cardano:" claimtokenref + +claimtokenref = "//claim" claimversion claimquery +claimversion = "/v1" | "/v2" +claimquery = ( "?" claimurl) ?( "&" claimcode) +claimurl = "faucet_url=" text +claimcode = "code=" text +``` + +### Token Claim URI Queries + +Token Claim URIs must include a path indicating protocol version and at minimum a `faucet_url` argument pointing to the +faucet hosted and maintained by the project. + +**All arguments for Token Claim URIs should be URL-encoded** + +***Version 1 URIs*** + +Version 1 URIs must include a `faucet_url` and a `code` as required parameters. + +***Version 2 URIs*** + +Version 2 URIs must include a `faucet_url` and may optionally include a `code` or other arguments per the needs of the +project's faucet API. + +### Handling Token Claim URI Queries + +The token claim URI should consist of a required versioning `path` (i.e. `/v1` or `/v2`) as well as one or more required +or optional URL-encoded arguments. + +All Token Claim URIs must include a URL-encoded `faucet_url` argument. The `code` argument is required for Version 1 +Claim URIs while being flagged as optional for Version 2 and beyond. + +The wallet provider should send a POST request to the provided `Faucet URL` that includes: +* The change/receipt wallet address of the user +* Any additional arguments specified in the URI as key: value pairs + +**Example:** + +``` +URI: web+cardano://claim/v1?faucet_url=https%3A%2F%2Fclaim.hosky.io%2Fconsensus23&code=ABC123 +Version: 1 +URL: https://claim.hosky.io/consensus23 +CODE: ABC123 +JSON POST Data: +``` +```json +{ + "address": "addr1abc...xyz", + "code": "ABC123" +} +``` + +#### Note on the `address` field + +The wallet should always send the recipient address in bech32 format. If a particular token faucet implementation wishes +to restrict or limit access to their faucet based on staking key or individual wallet address, this should be handled at +the wallet end. + +#### Note on the `code` field + +The code is required in Version 1 but specified as optional in Version 2 and beyond. Specifying a `code` allows for +reliable tracking and/or limiting of claims to the faucet host. Codes can be used to identify attendees of particular +events (i.e. CODE = `consensus2023`) or can be a unique, one-time code per user (i.e. CODE = `abc123xyz987`). In this +way we leave the code to be flexible to match a variety of analytical use cases depending upon the needs of the +implementing project. + +### Security Considerations + +1. For payment links, we cannot prompt the user to send the funds right away as they may not be fully aware of the URI they clicked or were redirected to. Instead, it may be better to simply pre-populate fields in a transaction. +2. For either payment or staking links, we should be wary of people who disguise links as actually opening up a phishing website that LOOKS like that corresponding part of the wallet UI. +3. If wallets *create* stake pool links, the actual ada or lovelace balance should not be used literally as the `proportion` figure, to avoid revealing the identity of the wallet owner who is creating the portfolio (e.g. the proportions could be scaled to normalise the largest to `1`). +4. Wallets should prompt/warn users prior to sending potentially sensitive information (wallet address + code) via the + token claim URI. An informational pop-up or confirmation modal should be displayed to users such as: + `We are about to send your address and code 123456 to https://claim.hosky.io. Are you sure you want to proceed?` + Additional specifications for this CIP relevant to CIP-13 have been made under the heading of "Token Claim URI" under its [README.md](../CIP-0013/README.md) @@ -125,34 +227,45 @@ including: * The user's wallet receive address * The code (if present in the URI [required for Version 1]) -_Examples:_ -```json -URI: web+cardano://claim/v1?faucet_url=https%3A%2F%2Fclaim.hosky.io -URL: https://claim.hosky.io -POST JSON Data: +### Examples + +#### _Faucet URL Only (v2+)_ +- URI: ```web+cardano://claim/v2?faucet_url=https%3A%2F%2Fclaim.hosky.io``` +- Faucet URL: ```https://claim.hosky.io``` +- POST JSON Data: +```json { "address": "addr1abc...xyz" } +``` -URI: web+cardano://claim/v1?faucet_url=https%3A%2F%2Fclaim.nftxlv.com&code=NFTxLV2023 -URL: https://claim.nftxlv.com -JSON POST Data: +#### _Faucet URL + Campaign Code (v1)_ +- URI: ```web+cardano://claim/v1?faucet_url=https%3A%2F%2Fclaim.nftxlv.com&code=NFTxLV2023``` +- Faucet URL: ```https://claim.nftxlv.com``` +- POST JSON Data: +```json { "address": "addr1abc...xyz", "code": "NFTxLV2023" } +``` -URI: web+cardano://claim/v1?faucet_url=https%3A%2F%2Fclaim.hosky.io&code=ABC123 -URL: https://claim.hosky.io -POST JSON Data: +#### _Faucet URL + Unique Code (v1)_ +- URI: ```web+cardano://claim/v1?faucet_url=https%3A%2F%2Fclaim.nftxlv.com&code=NFTxLV2023``` +- Faucet URL: ```https://claim.hosky.io``` +- POST JSON Data: +```json { "address": "addr1abc...xyz", "code": "ABC123" } +``` -URI: web+cardano://claim/v2?faucet_url=https%3A%2F%2Fclaim.nftxlv.com&code=NFTxLV2023&user_id=Adam1337 -URL: https://claim.nftxlv.com -POST JSON Data: +#### _Faucet URL + Campaign Code + Custom User ID (v2)_ +- URI: ```web+cardano://claim/v2?faucet_url=https%3A%2F%2Fclaim.nftxlv.com&code=NFTxLV2023&user_id=Adam1337``` +- Faucet URL: ```https://claim.nftxlv.com``` +- POST JSON Data: +```json { "address": "addr1abc...xyz", "code": "NFTxLV2023", From 3ef1e434d8fc56245fb8c05fa48d948161a3be12 Mon Sep 17 00:00:00 2001 From: Crypto2099 <63186174+Crypto2099@users.noreply.github.com> Date: Wed, 19 Jul 2023 07:20:06 -0700 Subject: [PATCH 06/54] Minor update to document progress on acceptance criteria and implementation actions taken in July 2023. --- CIP-XXXX/README.md | 15 ++++++++++++++- 1 file changed, 14 insertions(+), 1 deletion(-) diff --git a/CIP-XXXX/README.md b/CIP-XXXX/README.md index a3385c7e54..df7bb0a9e5 100644 --- a/CIP-XXXX/README.md +++ b/CIP-XXXX/README.md @@ -410,7 +410,7 @@ marketing and event efforts: Proof of Onboarding. ## Acceptance Criteria -- [ ] Demonstrate a working MVP +- [X] Demonstrate a working MVP - [ ] Open source an MVP example of token faucet server-side code - [ ] Receive feedback and iterate on Version 2 based on community feedback @@ -423,6 +423,19 @@ implementation should give us important insight on whether the system requires a From there we will do our best to engage with other teams and projects in the ecosystem to encourage and support adoption of this standard on a larger scale. +## Acceptance & Implementation Actions + +1. The Proof of Onboarding protocol was demonstrated via MVP during the Edinburgh, Scotland, UK CIP-1694 workshop hosted + by IOG in July 2023. This MVP demonstrated that the protocol works as described in this CIP and the overall feedback + from participants has been positive. This MVP was executed in collaboration with VESPR mobile Cardano wallet, HOSKY + token project, and Adam Dean as the distributor and architect of the specification. + 1. [X] VESPR Mobile Wallet as of the time of this writing has support for Version 1 of the Proof of Onboarding Protocol + and is freely available for the use of any and all projects. + 2. [ ] HOSKY Token project is working on finalizing and releasing a working, open source MVP for the software needed + to be run by the distributing project that will support fungible and non-fungible tokens or any combination thereof. + 3. [ ] Adam Dean is in talks with additional wallet providers to bring P.O.O. support to more platforms as well as + working on open source tooling to facilitate ease of implementation for other projects. + # Copyright This CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode). \ No newline at end of file From a58f6434cd69b9dd617e96976da02eecf8825f79 Mon Sep 17 00:00:00 2001 From: Crypto2099 <63186174+Crypto2099@users.noreply.github.com> Date: Wed, 19 Jul 2023 10:46:50 -0700 Subject: [PATCH 07/54] Update examples to properly reflect that the API server should return the tokens array with hex-encoded asset names and not ASCII asset names. --- CIP-XXXX/README.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/CIP-XXXX/README.md b/CIP-XXXX/README.md index df7bb0a9e5..55515f4ed1 100644 --- a/CIP-XXXX/README.md +++ b/CIP-XXXX/README.md @@ -297,7 +297,7 @@ First Successful Request "queue_position": 23, "status": "accepted", "tokens": { - "a0028f350aaabe0545fdcb56b039bfb08e4bb4d8c4d7c3c7d481c235.HOSKY": "29433292000000" + "a0028f350aaabe0545fdcb56b039bfb08e4bb4d8c4d7c3c7d481c235.484f534b59": "29433292000000" } } ``` @@ -313,7 +313,7 @@ Subsequent Successful Request (Address + Code Match) prior to token distribution "queue_position": 1, "status": "queued", "tokens": { - "a0028f350aaabe0545fdcb56b039bfb08e4bb4d8c4d7c3c7d481c235.HOSKY": "29433292000000" + "a0028f350aaabe0545fdcb56b039bfb08e4bb4d8c4d7c3c7d481c235.484f534b59": "29433292000000" } } ``` @@ -328,7 +328,7 @@ Subsequent Successful Request (Address + Code Match) after token(s) are distribu "lovelaces": "2000000", "status": "claimed", "tokens": { - "a0028f350aaabe0545fdcb56b039bfb08e4bb4d8c4d7c3c7d481c235.HOSKY": "29433292000000" + "a0028f350aaabe0545fdcb56b039bfb08e4bb4d8c4d7c3c7d481c235.484f534b59": "29433292000000" }, "tx_hash": "TX1234" } From 5395cb6e69491329d5fa8cf043a53dc75ad130fb Mon Sep 17 00:00:00 2001 From: Crypto2099 <63186174+Crypto2099@users.noreply.github.com> Date: Fri, 21 Jul 2023 10:48:29 -0700 Subject: [PATCH 08/54] Remove Version 2 for now as it is unnecessary at this time, let's keep it simple for the sake of early adoption. --- CIP-XXXX/README.md | 132 +++++++++++++++++++++------------------------ 1 file changed, 61 insertions(+), 71 deletions(-) diff --git a/CIP-XXXX/README.md b/CIP-XXXX/README.md index 55515f4ed1..6799a05de3 100644 --- a/CIP-XXXX/README.md +++ b/CIP-XXXX/README.md @@ -15,6 +15,8 @@ Created: 2023-06-20 License: CC-BY-4.0 --- +> Current Version: 1 + # Abstract Since at least 2021 when Cardano entered the Mary Era and implemented Native Assets, projects and creators building on @@ -66,19 +68,20 @@ Examples: Claim $HOSKY Claim $HOSKY -Claim NFTxLV Commermorative NFT! +Claim NFTxLV Commermorative NFT! ``` ### ABNF Grammar -* For a token claim URI (authority = `claim`), a versioning path, a `faucet_url` and an optional `code` (required in v1). +* For a token claim URI (authority = `claim`), a versioning path, a `faucet_url` and a required `code`. +* Additional query parameters may be provided and should be passed through to the provided `faucet_url` as-is. ``` cardanourn = "web+cardano:" claimtokenref claimtokenref = "//claim" claimversion claimquery claimversion = "/v1" | "/v2" -claimquery = ( "?" claimurl) ?( "&" claimcode) +claimquery = ( "?" claimurl) ( "&" claimcode) claimurl = "faucet_url=" text claimcode = "code=" text ``` @@ -92,20 +95,16 @@ faucet hosted and maintained by the project. ***Version 1 URIs*** -Version 1 URIs must include a `faucet_url` and a `code` as required parameters. - -***Version 2 URIs*** +Version 1 URIs must include a `faucet_url` and a `code` as required parameters. URIs may include additional arguments to +suit the needs of the project's faucet API. -Version 2 URIs must include a `faucet_url` and may optionally include a `code` or other arguments per the needs of the -project's faucet API. ### Handling Token Claim URI Queries -The token claim URI should consist of a required versioning `path` (i.e. `/v1` or `/v2`) as well as one or more required +The token claim URI should consist of a required versioning `path` (i.e. `/v1`) as well as one or more required or optional URL-encoded arguments. -All Token Claim URIs must include a URL-encoded `faucet_url` argument. The `code` argument is required for Version 1 -Claim URIs while being flagged as optional for Version 2 and beyond. +All Token Claim URIs must include a URL-encoded `faucet_url` argument as well as a `code` argument. The wallet provider should send a POST request to the provided `Faucet URL` that includes: * The change/receipt wallet address of the user @@ -135,24 +134,17 @@ the wallet end. #### Note on the `code` field -The code is required in Version 1 but specified as optional in Version 2 and beyond. Specifying a `code` allows for -reliable tracking and/or limiting of claims to the faucet host. Codes can be used to identify attendees of particular -events (i.e. CODE = `consensus2023`) or can be a unique, one-time code per user (i.e. CODE = `abc123xyz987`). In this -way we leave the code to be flexible to match a variety of analytical use cases depending upon the needs of the -implementing project. +The code is required. Specifying a `code` allows for reliable tracking and/or limiting of claims to the faucet host. +Codes can be used to identify attendees of particular events (i.e. CODE = `consensus2023`) or can be a unique, one-time +code per user (i.e. CODE = `abc123xyz987`). In this way we leave the code to be flexible to match a variety of +analytical use cases depending upon the needs of the implementing project. ### Security Considerations -1. For payment links, we cannot prompt the user to send the funds right away as they may not be fully aware of the URI they clicked or were redirected to. Instead, it may be better to simply pre-populate fields in a transaction. -2. For either payment or staking links, we should be wary of people who disguise links as actually opening up a phishing website that LOOKS like that corresponding part of the wallet UI. -3. If wallets *create* stake pool links, the actual ada or lovelace balance should not be used literally as the `proportion` figure, to avoid revealing the identity of the wallet owner who is creating the portfolio (e.g. the proportions could be scaled to normalise the largest to `1`). -4. Wallets should prompt/warn users prior to sending potentially sensitive information (wallet address + code) via the +1. Wallets should prompt/warn users prior to sending potentially sensitive information (wallet address + code) via the token claim URI. An informational pop-up or confirmation modal should be displayed to users such as: `We are about to send your address and code 123456 to https://claim.hosky.io. Are you sure you want to proceed?` -Additional specifications for this CIP relevant to CIP-13 have been made under the heading of "Token Claim URI" under -its [README.md](../CIP-0013/README.md) - ## Process Flow The envisioned process flow for the POO Protocol is as follows: @@ -179,45 +171,20 @@ Version 1 URIs must include two required arguments: * `faucet_url` as a fully-typed URL (i.e. https://claim.hosky.io) * `code` as either a campaign identifier or unique, one-time use code +Version 1 URIs may include additional query parameters that should be passed through to the api server. + _Version 1 Examples:_ ```html - + Thanks for attending Consensus 2023! - + Claim your $HOSKY now! -``` - -### Version 2 -Version 2 URIs must include `/v2` as the path of the URI - -Version 2 URIs must include one required argument: - -* `faucet_url` as a fully-typed URL (i.e. https://claim.hosky.io) - -Version 2 URIs may include additional, optional arguments: - -* `code` as either a campaign identifier or unique, one-time use code -* Additional arguments should be passed by the wallet to the API server in the JSON body of the POST request. - - -_Version 2 Examples:_ -```html - -Claim $HOSKY Now! - - -Claim your NFTxLV 2023 NFT now! - - -Claim Some $HOSKY! - - -Get your $HOSKY! + +Get your $HOSKY! ``` - ## Wallet Requests Light wallets that detect and support `web+cardano` URIs as well as mobile wallets who detect either a QR code or other @@ -225,21 +192,12 @@ link with this format should parse the URI and send a `POST` request to the spec including: * The user's wallet receive address -* The code (if present in the URI [required for Version 1]) +* The code +* Additional URI query parameters passed through ### Examples -#### _Faucet URL Only (v2+)_ -- URI: ```web+cardano://claim/v2?faucet_url=https%3A%2F%2Fclaim.hosky.io``` -- Faucet URL: ```https://claim.hosky.io``` -- POST JSON Data: -```json -{ - "address": "addr1abc...xyz" -} -``` - -#### _Faucet URL + Campaign Code (v1)_ +#### _Faucet URL + Campaign Code_ - URI: ```web+cardano://claim/v1?faucet_url=https%3A%2F%2Fclaim.nftxlv.com&code=NFTxLV2023``` - Faucet URL: ```https://claim.nftxlv.com``` - POST JSON Data: @@ -250,7 +208,7 @@ including: } ``` -#### _Faucet URL + Unique Code (v1)_ +#### _Faucet URL + Unique Code_ - URI: ```web+cardano://claim/v1?faucet_url=https%3A%2F%2Fclaim.nftxlv.com&code=NFTxLV2023``` - Faucet URL: ```https://claim.hosky.io``` - POST JSON Data: @@ -261,8 +219,8 @@ including: } ``` -#### _Faucet URL + Campaign Code + Custom User ID (v2)_ -- URI: ```web+cardano://claim/v2?faucet_url=https%3A%2F%2Fclaim.nftxlv.com&code=NFTxLV2023&user_id=Adam1337``` +#### _Faucet URL + Campaign Code + Custom User ID_ +- URI: ```web+cardano://claim/v1?faucet_url=https%3A%2F%2Fclaim.nftxlv.com&code=NFTxLV2023&user_id=Adam1337``` - Faucet URL: ```https://claim.nftxlv.com``` - POST JSON Data: ```json @@ -282,7 +240,6 @@ The expected API that any token fountain implementation should follow and wallet on Swagger! * [Version 1](https://app.swaggerhub.com/apis/CatastrophicCardano/FaucetAPI/1) -* [Version 2](https://app.swaggerhub.com/apis/CatastrophicCardano/FaucetAPI/2) ### Successful Responses @@ -336,6 +293,39 @@ Subsequent Successful Request (Address + Code Match) after token(s) are distribu ### Error Responses +#### Bad Request - Invalid Address (400) + +The provided address is not a valid Cardano address + +```json +{ + "code": 400, + "status": "invalidaddress" +} +``` + +#### Bad Request - Missing Code (400) + +No code was provided in the request + +```json +{ + "code": 400, + "status": "missingcode" +} +``` + +#### Bad Request - Invalid Network (400) + +The wallet provided is from the wrong network (testnet/mainnet) + +```json +{ + "code": 400, + "status": "invalidnetwork" +} +``` + #### Invalid - Not Known (404) The specified code does not exist @@ -412,7 +402,7 @@ marketing and event efforts: Proof of Onboarding. - [X] Demonstrate a working MVP - [ ] Open source an MVP example of token faucet server-side code -- [ ] Receive feedback and iterate on Version 2 based on community feedback +- [ ] Receive feedback and iterate based on community feedback ## Implementation Plan From ce2052f2572a57807c8e2e168cd7132dbd9eede6 Mon Sep 17 00:00:00 2001 From: Crypto2099 <63186174+Crypto2099@users.noreply.github.com> Date: Fri, 21 Jul 2023 10:51:53 -0700 Subject: [PATCH 09/54] Fix minor typo in an example --- CIP-XXXX/README.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/CIP-XXXX/README.md b/CIP-XXXX/README.md index 6799a05de3..7949e98cd3 100644 --- a/CIP-XXXX/README.md +++ b/CIP-XXXX/README.md @@ -68,7 +68,7 @@ Examples: Claim $HOSKY Claim $HOSKY -Claim NFTxLV Commermorative NFT! +Claim NFTxLV Commermorative NFT! ``` ### ABNF Grammar @@ -80,7 +80,7 @@ Examples: cardanourn = "web+cardano:" claimtokenref claimtokenref = "//claim" claimversion claimquery -claimversion = "/v1" | "/v2" +claimversion = "/v1" claimquery = ( "?" claimurl) ( "&" claimcode) claimurl = "faucet_url=" text claimcode = "code=" text From 55cb55d1d113a2020808a15760183aa804e9acc0 Mon Sep 17 00:00:00 2001 From: Robert Phair Date: Mon, 24 Jul 2023 22:42:46 +0530 Subject: [PATCH 10/54] fix header level --- CIP-XXXX/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CIP-XXXX/README.md b/CIP-XXXX/README.md index 7949e98cd3..3664a2e84d 100644 --- a/CIP-XXXX/README.md +++ b/CIP-XXXX/README.md @@ -17,7 +17,7 @@ License: CC-BY-4.0 > Current Version: 1 -# Abstract +## Abstract Since at least 2021 when Cardano entered the Mary Era and implemented Native Assets, projects and creators building on the network have sought a means to distribute their tokens efficiently to users. Of particular frustration has been the From 62a4ef6d95b4462bd719be744122076e83b68ddf Mon Sep 17 00:00:00 2001 From: Robert Phair Date: Mon, 24 Jul 2023 22:42:59 +0530 Subject: [PATCH 11/54] fix header level --- CIP-XXXX/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CIP-XXXX/README.md b/CIP-XXXX/README.md index 3664a2e84d..bd5d0d559e 100644 --- a/CIP-XXXX/README.md +++ b/CIP-XXXX/README.md @@ -33,7 +33,7 @@ wallet to reward, incentivize, and onboard new users easier than ever. This CIP defines an extension to the CIP-13 URI Scheme as well as an API specification to facilitate and streamline communications between wallets and project servers. -# Motivation: Why is this CIP necessary? +## Motivation: Why is this CIP necessary? By leveraging the power of Cardano-specific URIs (CIP-13) and the modern technological advances of mobile devices and wallets we can provide a framework for Cardano projects to attend real world events, incentivize or reward attendees via From 7b4e8e56c56b0d11222470ef2e6de867d642552d Mon Sep 17 00:00:00 2001 From: Robert Phair Date: Mon, 24 Jul 2023 22:43:09 +0530 Subject: [PATCH 12/54] fix header level --- CIP-XXXX/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CIP-XXXX/README.md b/CIP-XXXX/README.md index bd5d0d559e..d54309c733 100644 --- a/CIP-XXXX/README.md +++ b/CIP-XXXX/README.md @@ -48,7 +48,7 @@ Furthermore, the aforementioned "paper wallet" technique has many drawbacks incl We feel that this is necessary as a CIP in order to minimize friction for new projects while maximizing compatibility across the wide spectrum of Cardano wallets. -# Specification +## Specification ## CIP-13 Cardano URI Extensions From 397686be7bed9821bccea53968ef8b71a0259257 Mon Sep 17 00:00:00 2001 From: Robert Phair Date: Mon, 24 Jul 2023 22:43:23 +0530 Subject: [PATCH 13/54] fix header level --- CIP-XXXX/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CIP-XXXX/README.md b/CIP-XXXX/README.md index d54309c733..5f569c2c3f 100644 --- a/CIP-XXXX/README.md +++ b/CIP-XXXX/README.md @@ -50,7 +50,7 @@ across the wide spectrum of Cardano wallets. ## Specification -## CIP-13 Cardano URI Extensions +### CIP-13 Cardano URI Extensions Distributing Native Assets (and/or ADA) to attendees of IRL events has historically been a pain point in the ecosystem. Some implemented solutions have included: Pre-generating wallet seed phrases and pre-populating these wallets with a From 7b962dc365b0779e48382985a936bc07ae4a2492 Mon Sep 17 00:00:00 2001 From: Robert Phair Date: Mon, 24 Jul 2023 22:43:40 +0530 Subject: [PATCH 14/54] fix header level --- CIP-XXXX/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CIP-XXXX/README.md b/CIP-XXXX/README.md index 5f569c2c3f..62742e62ea 100644 --- a/CIP-XXXX/README.md +++ b/CIP-XXXX/README.md @@ -71,7 +71,7 @@ Examples: Claim NFTxLV Commermorative NFT! ``` -### ABNF Grammar +#### ABNF Grammar * For a token claim URI (authority = `claim`), a versioning path, a `faucet_url` and a required `code`. * Additional query parameters may be provided and should be passed through to the provided `faucet_url` as-is. From 89496b33cb3006148d9d99af3f27f18dcf040244 Mon Sep 17 00:00:00 2001 From: Robert Phair Date: Mon, 24 Jul 2023 22:44:11 +0530 Subject: [PATCH 15/54] fix header level --- CIP-XXXX/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CIP-XXXX/README.md b/CIP-XXXX/README.md index 62742e62ea..c664a7fbd3 100644 --- a/CIP-XXXX/README.md +++ b/CIP-XXXX/README.md @@ -86,7 +86,7 @@ claimurl = "faucet_url=" text claimcode = "code=" text ``` -### Token Claim URI Queries +#### Token Claim URI Queries Token Claim URIs must include a path indicating protocol version and at minimum a `faucet_url` argument pointing to the faucet hosted and maintained by the project. From d7155ca2f15d9fe20ada428249854d10070c57f8 Mon Sep 17 00:00:00 2001 From: Robert Phair Date: Mon, 24 Jul 2023 22:44:28 +0530 Subject: [PATCH 16/54] fix header level --- CIP-XXXX/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CIP-XXXX/README.md b/CIP-XXXX/README.md index c664a7fbd3..101bc77a49 100644 --- a/CIP-XXXX/README.md +++ b/CIP-XXXX/README.md @@ -99,7 +99,7 @@ Version 1 URIs must include a `faucet_url` and a `code` as required parameters. suit the needs of the project's faucet API. -### Handling Token Claim URI Queries +#### Handling Token Claim URI Queries The token claim URI should consist of a required versioning `path` (i.e. `/v1`) as well as one or more required or optional URL-encoded arguments. From d59aa42785d5cc7a93ad7cd9a30ca4b9acdc3182 Mon Sep 17 00:00:00 2001 From: Robert Phair Date: Mon, 24 Jul 2023 22:44:46 +0530 Subject: [PATCH 17/54] fix header level --- CIP-XXXX/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CIP-XXXX/README.md b/CIP-XXXX/README.md index 101bc77a49..e5e9098117 100644 --- a/CIP-XXXX/README.md +++ b/CIP-XXXX/README.md @@ -126,7 +126,7 @@ JSON POST Data: } ``` -#### Note on the `address` field +##### Note on the `address` field The wallet should always send the recipient address in bech32 format. If a particular token faucet implementation wishes to restrict or limit access to their faucet based on staking key or individual wallet address, this should be handled at From 432bc38aed9197c685a03da6cb9d94e28eddf377 Mon Sep 17 00:00:00 2001 From: Robert Phair Date: Mon, 24 Jul 2023 22:45:03 +0530 Subject: [PATCH 18/54] fix header level --- CIP-XXXX/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CIP-XXXX/README.md b/CIP-XXXX/README.md index e5e9098117..809fa7e35d 100644 --- a/CIP-XXXX/README.md +++ b/CIP-XXXX/README.md @@ -132,7 +132,7 @@ The wallet should always send the recipient address in bech32 format. If a parti to restrict or limit access to their faucet based on staking key or individual wallet address, this should be handled at the wallet end. -#### Note on the `code` field +##### Note on the `code` field The code is required. Specifying a `code` allows for reliable tracking and/or limiting of claims to the faucet host. Codes can be used to identify attendees of particular events (i.e. CODE = `consensus2023`) or can be a unique, one-time From b614843b00f71ec4913aa1fa2eb0106e280412f0 Mon Sep 17 00:00:00 2001 From: Robert Phair Date: Mon, 24 Jul 2023 22:45:20 +0530 Subject: [PATCH 19/54] fix header level --- CIP-XXXX/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CIP-XXXX/README.md b/CIP-XXXX/README.md index 809fa7e35d..f18dd8986b 100644 --- a/CIP-XXXX/README.md +++ b/CIP-XXXX/README.md @@ -139,7 +139,7 @@ Codes can be used to identify attendees of particular events (i.e. CODE = `conse code per user (i.e. CODE = `abc123xyz987`). In this way we leave the code to be flexible to match a variety of analytical use cases depending upon the needs of the implementing project. -### Security Considerations +#### Security Considerations 1. Wallets should prompt/warn users prior to sending potentially sensitive information (wallet address + code) via the token claim URI. An informational pop-up or confirmation modal should be displayed to users such as: From a7f3bcf967a74b9e4c2127deae2acf83aafe043a Mon Sep 17 00:00:00 2001 From: Robert Phair Date: Mon, 24 Jul 2023 22:45:40 +0530 Subject: [PATCH 20/54] fix header level --- CIP-XXXX/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CIP-XXXX/README.md b/CIP-XXXX/README.md index f18dd8986b..944c1271e0 100644 --- a/CIP-XXXX/README.md +++ b/CIP-XXXX/README.md @@ -145,7 +145,7 @@ analytical use cases depending upon the needs of the implementing project. token claim URI. An informational pop-up or confirmation modal should be displayed to users such as: `We are about to send your address and code 123456 to https://claim.hosky.io. Are you sure you want to proceed?` -## Process Flow +### Process Flow The envisioned process flow for the POO Protocol is as follows: 1. The project set asides some amount of budget (tokens + Lovelace [minUTxO]) for a given marketing push or IRL event From 4d8d396fd64450cf9bfa9cb2d367d1edbcf11053 Mon Sep 17 00:00:00 2001 From: Robert Phair Date: Mon, 24 Jul 2023 22:45:58 +0530 Subject: [PATCH 21/54] fix header level --- CIP-XXXX/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CIP-XXXX/README.md b/CIP-XXXX/README.md index 944c1271e0..28deac11f3 100644 --- a/CIP-XXXX/README.md +++ b/CIP-XXXX/README.md @@ -156,7 +156,7 @@ The envisioned process flow for the POO Protocol is as follows: 6. The project API returns a documented status code indicating the success or failure of the operation 7. If a successful status is detected and returned, the project issues tokens to the specified address per their campaign settings -## URI Format +### URI Format The URI format consists of the CIP-13 `web+cardano://` scheme, followed by the `claim` authority, then a `version` path. From b387a935e8490095101ec790d932d0b4f4bfe551 Mon Sep 17 00:00:00 2001 From: Robert Phair Date: Mon, 24 Jul 2023 22:46:30 +0530 Subject: [PATCH 22/54] fix header level --- CIP-XXXX/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CIP-XXXX/README.md b/CIP-XXXX/README.md index 28deac11f3..c824702492 100644 --- a/CIP-XXXX/README.md +++ b/CIP-XXXX/README.md @@ -162,7 +162,7 @@ The URI format consists of the CIP-13 `web+cardano://` scheme, followed by the ` ***NOTE: ALL ARGUMENTS SHOULD BE URL-ENCODED*** -### Version 1 +#### Version 1 Version 1 URIs must include `/v1` as the path of the URI. From 5c86d3b5e53778f4335576fb25c16cf87b0a1ff8 Mon Sep 17 00:00:00 2001 From: Robert Phair Date: Mon, 24 Jul 2023 22:47:04 +0530 Subject: [PATCH 23/54] fix header level --- CIP-XXXX/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CIP-XXXX/README.md b/CIP-XXXX/README.md index c824702492..1a788e3b77 100644 --- a/CIP-XXXX/README.md +++ b/CIP-XXXX/README.md @@ -185,7 +185,7 @@ _Version 1 Examples:_ Get your $HOSKY! ``` -## Wallet Requests +### Wallet Requests Light wallets that detect and support `web+cardano` URIs as well as mobile wallets who detect either a QR code or other link with this format should parse the URI and send a `POST` request to the specified URL containing a JSON payload From aa3be9e32d44bd34927e3086de329f60abc794b0 Mon Sep 17 00:00:00 2001 From: Robert Phair Date: Mon, 24 Jul 2023 22:47:20 +0530 Subject: [PATCH 24/54] fix header level --- CIP-XXXX/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CIP-XXXX/README.md b/CIP-XXXX/README.md index 1a788e3b77..9fd9bf9404 100644 --- a/CIP-XXXX/README.md +++ b/CIP-XXXX/README.md @@ -195,7 +195,7 @@ including: * The code * Additional URI query parameters passed through -### Examples +#### Examples #### _Faucet URL + Campaign Code_ - URI: ```web+cardano://claim/v1?faucet_url=https%3A%2F%2Fclaim.nftxlv.com&code=NFTxLV2023``` From e838de981d92e99fb6b36c771bb326bcc3a95113 Mon Sep 17 00:00:00 2001 From: Robert Phair Date: Mon, 24 Jul 2023 22:47:39 +0530 Subject: [PATCH 25/54] fix header level --- CIP-XXXX/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CIP-XXXX/README.md b/CIP-XXXX/README.md index 9fd9bf9404..0efc8ddfdf 100644 --- a/CIP-XXXX/README.md +++ b/CIP-XXXX/README.md @@ -197,7 +197,7 @@ including: #### Examples -#### _Faucet URL + Campaign Code_ +##### _Faucet URL + Campaign Code_ - URI: ```web+cardano://claim/v1?faucet_url=https%3A%2F%2Fclaim.nftxlv.com&code=NFTxLV2023``` - Faucet URL: ```https://claim.nftxlv.com``` - POST JSON Data: From 1e50339bb04e93328776ab074a2c72e09abe5dea Mon Sep 17 00:00:00 2001 From: Robert Phair Date: Mon, 24 Jul 2023 22:47:55 +0530 Subject: [PATCH 26/54] fix header level --- CIP-XXXX/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CIP-XXXX/README.md b/CIP-XXXX/README.md index 0efc8ddfdf..acb3eafd59 100644 --- a/CIP-XXXX/README.md +++ b/CIP-XXXX/README.md @@ -208,7 +208,7 @@ including: } ``` -#### _Faucet URL + Unique Code_ +##### _Faucet URL + Unique Code_ - URI: ```web+cardano://claim/v1?faucet_url=https%3A%2F%2Fclaim.nftxlv.com&code=NFTxLV2023``` - Faucet URL: ```https://claim.hosky.io``` - POST JSON Data: From a6ad3edc6725f2bede85f174ef81f560a2c72114 Mon Sep 17 00:00:00 2001 From: Robert Phair Date: Mon, 24 Jul 2023 22:48:16 +0530 Subject: [PATCH 27/54] fix header level --- CIP-XXXX/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CIP-XXXX/README.md b/CIP-XXXX/README.md index acb3eafd59..96565ad519 100644 --- a/CIP-XXXX/README.md +++ b/CIP-XXXX/README.md @@ -219,7 +219,7 @@ including: } ``` -#### _Faucet URL + Campaign Code + Custom User ID_ +##### _Faucet URL + Campaign Code + Custom User ID_ - URI: ```web+cardano://claim/v1?faucet_url=https%3A%2F%2Fclaim.nftxlv.com&code=NFTxLV2023&user_id=Adam1337``` - Faucet URL: ```https://claim.nftxlv.com``` - POST JSON Data: From dca1aceac06b8315860125acaaa689ff9d0aef9e Mon Sep 17 00:00:00 2001 From: Robert Phair Date: Mon, 24 Jul 2023 22:48:35 +0530 Subject: [PATCH 28/54] fix header level --- CIP-XXXX/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CIP-XXXX/README.md b/CIP-XXXX/README.md index 96565ad519..9d796e9fc4 100644 --- a/CIP-XXXX/README.md +++ b/CIP-XXXX/README.md @@ -231,7 +231,7 @@ including: } ``` -## API Server Response Codes +### API Server Response Codes The API server is expected to return one of the following defined status blocks in `application/json` format. Any other responses from the API server should be considered invalid and discarded or display an error. From 6315cc63b15fffc6b0ad4b0e9edf54dd0dfb0d65 Mon Sep 17 00:00:00 2001 From: Robert Phair Date: Mon, 24 Jul 2023 22:48:50 +0530 Subject: [PATCH 29/54] fix header level --- CIP-XXXX/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CIP-XXXX/README.md b/CIP-XXXX/README.md index 9d796e9fc4..3bf032427d 100644 --- a/CIP-XXXX/README.md +++ b/CIP-XXXX/README.md @@ -241,7 +241,7 @@ on Swagger! * [Version 1](https://app.swaggerhub.com/apis/CatastrophicCardano/FaucetAPI/1) -### Successful Responses +#### Successful Responses #### Valid (200) From 559aab52ce17bcbc7945a9cc66ad8827980d239e Mon Sep 17 00:00:00 2001 From: Robert Phair Date: Mon, 24 Jul 2023 22:49:05 +0530 Subject: [PATCH 30/54] fix header level --- CIP-XXXX/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CIP-XXXX/README.md b/CIP-XXXX/README.md index 3bf032427d..7e20b0519a 100644 --- a/CIP-XXXX/README.md +++ b/CIP-XXXX/README.md @@ -243,7 +243,7 @@ on Swagger! #### Successful Responses -#### Valid (200) +##### Valid (200) First Successful Request From a4b6f3ac184dd7f95a7e1c16ec52bf9b35fd27ec Mon Sep 17 00:00:00 2001 From: Robert Phair Date: Mon, 24 Jul 2023 22:49:25 +0530 Subject: [PATCH 31/54] fix header level --- CIP-XXXX/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CIP-XXXX/README.md b/CIP-XXXX/README.md index 7e20b0519a..b031a50287 100644 --- a/CIP-XXXX/README.md +++ b/CIP-XXXX/README.md @@ -259,7 +259,7 @@ First Successful Request } ``` -#### Valid Queued (201) +##### Valid Queued (201) Subsequent Successful Request (Address + Code Match) prior to token distribution From 316cd21e984f26947b3c7768048b852bb53bf5c3 Mon Sep 17 00:00:00 2001 From: Robert Phair Date: Mon, 24 Jul 2023 22:49:45 +0530 Subject: [PATCH 32/54] fix header level --- CIP-XXXX/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CIP-XXXX/README.md b/CIP-XXXX/README.md index b031a50287..29e3abb082 100644 --- a/CIP-XXXX/README.md +++ b/CIP-XXXX/README.md @@ -275,7 +275,7 @@ Subsequent Successful Request (Address + Code Match) prior to token distribution } ``` -#### Valid Complete (202) +##### Valid Complete (202) Subsequent Successful Request (Address + Code Match) after token(s) are distributed From a96de151fe31d7846686c9180b50d08c1d8c4274 Mon Sep 17 00:00:00 2001 From: Robert Phair Date: Mon, 24 Jul 2023 22:50:11 +0530 Subject: [PATCH 33/54] fix header level --- CIP-XXXX/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CIP-XXXX/README.md b/CIP-XXXX/README.md index 29e3abb082..0dff99d2e4 100644 --- a/CIP-XXXX/README.md +++ b/CIP-XXXX/README.md @@ -291,7 +291,7 @@ Subsequent Successful Request (Address + Code Match) after token(s) are distribu } ``` -### Error Responses +#### Error Responses #### Bad Request - Invalid Address (400) From 207212a338820e8165bfbf134ca443d493629cad Mon Sep 17 00:00:00 2001 From: Robert Phair Date: Mon, 24 Jul 2023 22:50:41 +0530 Subject: [PATCH 34/54] fix header level --- CIP-XXXX/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CIP-XXXX/README.md b/CIP-XXXX/README.md index 0dff99d2e4..3ea65f527b 100644 --- a/CIP-XXXX/README.md +++ b/CIP-XXXX/README.md @@ -293,7 +293,7 @@ Subsequent Successful Request (Address + Code Match) after token(s) are distribu #### Error Responses -#### Bad Request - Invalid Address (400) +##### Bad Request - Invalid Address (400) The provided address is not a valid Cardano address From a5bb8a25db479a2ae65b42fbd7c781342ad20b64 Mon Sep 17 00:00:00 2001 From: Robert Phair Date: Mon, 24 Jul 2023 22:51:11 +0530 Subject: [PATCH 35/54] fix header level --- CIP-XXXX/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CIP-XXXX/README.md b/CIP-XXXX/README.md index 3ea65f527b..17336b9604 100644 --- a/CIP-XXXX/README.md +++ b/CIP-XXXX/README.md @@ -304,7 +304,7 @@ The provided address is not a valid Cardano address } ``` -#### Bad Request - Missing Code (400) +##### Bad Request - Missing Code (400) No code was provided in the request From 900c07f2fa1b8db40ce0b3b59878315b148d9c05 Mon Sep 17 00:00:00 2001 From: Robert Phair Date: Mon, 24 Jul 2023 22:51:32 +0530 Subject: [PATCH 36/54] fix header level --- CIP-XXXX/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CIP-XXXX/README.md b/CIP-XXXX/README.md index 17336b9604..6b544c7f7f 100644 --- a/CIP-XXXX/README.md +++ b/CIP-XXXX/README.md @@ -315,7 +315,7 @@ No code was provided in the request } ``` -#### Bad Request - Invalid Network (400) +##### Bad Request - Invalid Network (400) The wallet provided is from the wrong network (testnet/mainnet) From 47eb7a93e619ccf9b98fc0b1958efb3bf20d6dcf Mon Sep 17 00:00:00 2001 From: Robert Phair Date: Mon, 24 Jul 2023 22:52:00 +0530 Subject: [PATCH 37/54] fix header level --- CIP-XXXX/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CIP-XXXX/README.md b/CIP-XXXX/README.md index 6b544c7f7f..1b184adc63 100644 --- a/CIP-XXXX/README.md +++ b/CIP-XXXX/README.md @@ -326,7 +326,7 @@ The wallet provided is from the wrong network (testnet/mainnet) } ``` -#### Invalid - Not Known (404) +##### Invalid - Not Known (404) The specified code does not exist From d52918ed5381c89a1a67d8b0e55a572a11e619dd Mon Sep 17 00:00:00 2001 From: Robert Phair Date: Mon, 24 Jul 2023 22:52:37 +0530 Subject: [PATCH 38/54] fix header level --- CIP-XXXX/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CIP-XXXX/README.md b/CIP-XXXX/README.md index 1b184adc63..d10fcaf9f1 100644 --- a/CIP-XXXX/README.md +++ b/CIP-XXXX/README.md @@ -337,7 +337,7 @@ The specified code does not exist } ``` -#### Invalid - Already Claimed (409) +##### Invalid - Already Claimed (409) An address was already used (if not code present) or the code presented was found but the address did not match From ca3bad34a1df8de69c5944d2e280c2327357fb9c Mon Sep 17 00:00:00 2001 From: Robert Phair Date: Mon, 24 Jul 2023 22:52:59 +0530 Subject: [PATCH 39/54] fix header level --- CIP-XXXX/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CIP-XXXX/README.md b/CIP-XXXX/README.md index d10fcaf9f1..ff65ea73f9 100644 --- a/CIP-XXXX/README.md +++ b/CIP-XXXX/README.md @@ -348,7 +348,7 @@ An address was already used (if not code present) or the code presented was foun } ``` -#### Invalid - Expired (410) +##### Invalid - Expired (410) For time-limited fountains, a code of 410 means that the period for redemption has expired From 5eb65d309ab111c1e07753c8311eea140c3dadfc Mon Sep 17 00:00:00 2001 From: Robert Phair Date: Mon, 24 Jul 2023 22:53:21 +0530 Subject: [PATCH 40/54] fix header level --- CIP-XXXX/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CIP-XXXX/README.md b/CIP-XXXX/README.md index ff65ea73f9..340c683e2a 100644 --- a/CIP-XXXX/README.md +++ b/CIP-XXXX/README.md @@ -359,7 +359,7 @@ For time-limited fountains, a code of 410 means that the period for redemption h } ``` -#### Invalid - Too Early (425) +##### Invalid - Too Early (425) For time-limited fountains, a code of 425 means that the period for redemption has not begun yet From bc45e545cb0fd202fef69de12b02168e1528eb27 Mon Sep 17 00:00:00 2001 From: Robert Phair Date: Mon, 24 Jul 2023 22:53:39 +0530 Subject: [PATCH 41/54] fix header level --- CIP-XXXX/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CIP-XXXX/README.md b/CIP-XXXX/README.md index 340c683e2a..768902dc73 100644 --- a/CIP-XXXX/README.md +++ b/CIP-XXXX/README.md @@ -370,7 +370,7 @@ For time-limited fountains, a code of 425 means that the period for redemption h } ``` -#### Invalid - Rate Limited (429) +##### Invalid - Rate Limited (429) Rate limiting settings and details are left to the discretion and implementation of individual projects. A status code of 429 or this status response should be considered as a rate limiting response. From 8079927076350e471c413dbc54c5384eb2821f26 Mon Sep 17 00:00:00 2001 From: Robert Phair Date: Mon, 24 Jul 2023 22:54:19 +0530 Subject: [PATCH 42/54] fix header level --- CIP-XXXX/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CIP-XXXX/README.md b/CIP-XXXX/README.md index 768902dc73..9a8d4abefa 100644 --- a/CIP-XXXX/README.md +++ b/CIP-XXXX/README.md @@ -382,7 +382,7 @@ of 429 or this status response should be considered as a rate limiting response. } ``` -#### Server Error (500) +##### Server Error (500) Implementations should of course be prepared to handle situations where a server is non-responsive for any reason and be prepared to handle any other, non-specified error codes including 500 codes. From 7498b47a030b8eb5f47665791ed8f443d9bff582 Mon Sep 17 00:00:00 2001 From: Robert Phair Date: Mon, 24 Jul 2023 22:55:05 +0530 Subject: [PATCH 43/54] fix header level & add explicit section title --- CIP-XXXX/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CIP-XXXX/README.md b/CIP-XXXX/README.md index 9a8d4abefa..6cf9a548c3 100644 --- a/CIP-XXXX/README.md +++ b/CIP-XXXX/README.md @@ -387,7 +387,7 @@ of 429 or this status response should be considered as a rate limiting response. Implementations should of course be prepared to handle situations where a server is non-responsive for any reason and be prepared to handle any other, non-specified error codes including 500 codes. -# Rationale +## Rationale: How does this CIP achieve its goals? By creating a well-defined standard for both a CIP-13 URI scheme and the expected API response(s) we can create a framework that both wallets and projects can utilize to encourage and onboard new users into the ecosystem via Native From 787dfdab78416a09b9f73aa433013a9d05b7b53e Mon Sep 17 00:00:00 2001 From: Robert Phair Date: Mon, 24 Jul 2023 22:55:29 +0530 Subject: [PATCH 44/54] fix header level --- CIP-XXXX/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CIP-XXXX/README.md b/CIP-XXXX/README.md index 6cf9a548c3..c6d87cec90 100644 --- a/CIP-XXXX/README.md +++ b/CIP-XXXX/README.md @@ -396,7 +396,7 @@ Asset incentive models without needlessly and constantly reinventing the wheel f By utilizing this framework, projects can have accurate, measurable analytics into the success of various real-world marketing and event efforts: Proof of Onboarding. -# Path to Active +## Path to Active ## Acceptance Criteria From 57cc62c0dd221d81085067404d424042b63a639f Mon Sep 17 00:00:00 2001 From: Robert Phair Date: Mon, 24 Jul 2023 22:55:49 +0530 Subject: [PATCH 45/54] fix header level --- CIP-XXXX/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CIP-XXXX/README.md b/CIP-XXXX/README.md index c6d87cec90..b0d541aaf9 100644 --- a/CIP-XXXX/README.md +++ b/CIP-XXXX/README.md @@ -398,7 +398,7 @@ marketing and event efforts: Proof of Onboarding. ## Path to Active -## Acceptance Criteria +### Acceptance Criteria - [X] Demonstrate a working MVP - [ ] Open source an MVP example of token faucet server-side code From 11e54a361a62a3d8672ee297a2aa5c4adba51c64 Mon Sep 17 00:00:00 2001 From: Robert Phair Date: Mon, 24 Jul 2023 22:56:13 +0530 Subject: [PATCH 46/54] fix header level --- CIP-XXXX/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CIP-XXXX/README.md b/CIP-XXXX/README.md index b0d541aaf9..164b59b862 100644 --- a/CIP-XXXX/README.md +++ b/CIP-XXXX/README.md @@ -404,7 +404,7 @@ marketing and event efforts: Proof of Onboarding. - [ ] Open source an MVP example of token faucet server-side code - [ ] Receive feedback and iterate based on community feedback -## Implementation Plan +### Implementation Plan In order to encourage adoption of this standard the authors commit to execute a functional a minimum viable product proof of concept demonstration in partnership between Adam Dean, HOSKY Token, and VESPR wallet. This real-world From 0d9b27f9ecf6208c18a03c87fc26a4f394cf01e7 Mon Sep 17 00:00:00 2001 From: Robert Phair Date: Mon, 24 Jul 2023 22:56:40 +0530 Subject: [PATCH 47/54] fix header level --- CIP-XXXX/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CIP-XXXX/README.md b/CIP-XXXX/README.md index 164b59b862..3cea9b4bad 100644 --- a/CIP-XXXX/README.md +++ b/CIP-XXXX/README.md @@ -426,6 +426,6 @@ adoption of this standard on a larger scale. 3. [ ] Adam Dean is in talks with additional wallet providers to bring P.O.O. support to more platforms as well as working on open source tooling to facilitate ease of implementation for other projects. -# Copyright +## Copyright This CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode). \ No newline at end of file From fa2e5841fbb5b4c82d8d3c2098df4a34b5883024 Mon Sep 17 00:00:00 2001 From: Ryan Williams <44342099+Ryun1@users.noreply.github.com> Date: Tue, 5 Sep 2023 17:44:05 +0100 Subject: [PATCH 48/54] Update CIP-XXXX/README.md --- CIP-XXXX/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CIP-XXXX/README.md b/CIP-XXXX/README.md index 3cea9b4bad..dd69c712bc 100644 --- a/CIP-XXXX/README.md +++ b/CIP-XXXX/README.md @@ -1,5 +1,5 @@ --- -CIP: CIP-???? +CIP: CIP-0099 Title: Proof of Onboarding Status: Proposed Category: Wallets From 4728cec3a1105f850dff9dd1abb37a798a37e3a2 Mon Sep 17 00:00:00 2001 From: Robert Phair Date: Tue, 5 Sep 2023 13:07:19 -0400 Subject: [PATCH 49/54] fixed glitch from edit during CIP meeting --- CIP-XXXX/README.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/CIP-XXXX/README.md b/CIP-XXXX/README.md index dd69c712bc..09175ddff0 100644 --- a/CIP-XXXX/README.md +++ b/CIP-XXXX/README.md @@ -1,5 +1,5 @@ --- -CIP: CIP-0099 +CIP: 99 Title: Proof of Onboarding Status: Proposed Category: Wallets @@ -428,4 +428,4 @@ adoption of this standard on a larger scale. ## Copyright -This CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode). \ No newline at end of file +This CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode). From 819b8f2f8735d64ee231f2861ac67656704545a9 Mon Sep 17 00:00:00 2001 From: Adam Dean <63186174+Crypto2099@users.noreply.github.com> Date: Wed, 8 Nov 2023 17:55:43 -0700 Subject: [PATCH 50/54] Update CIP-XXXX/README.md Co-authored-by: Ryan Williams <44342099+Ryun1@users.noreply.github.com> --- CIP-XXXX/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CIP-XXXX/README.md b/CIP-XXXX/README.md index 09175ddff0..01b8253a4c 100644 --- a/CIP-XXXX/README.md +++ b/CIP-XXXX/README.md @@ -25,7 +25,7 @@ ability to onboard new users at real-world events. Solutions for this historical "paper wallets" where a seed phrase and accompanying password is generated by the project, pre-populated with tokens and ADA, and then delivered over to attendees of said event. -The creation of this addendum to the CIP-13 Cardano URI scheme seeks to minimize this friction and take advantage of +The creation of this addendum to the [CIP-13 Cardano URI scheme](https://github.com/cardano-foundation/CIPs/blob/master/CIP-0013/README.md) seeks to minimize this friction and take advantage of existing technology to enable a new era of user onboarding, particularly at real world events through the use of a defined URI scheme enabling instant and frictionless communication between a project's "token fountain" and the user's wallet to reward, incentivize, and onboard new users easier than ever. From 7a06fedf1bd0e60a2ca5f28a415228923d5cfa5b Mon Sep 17 00:00:00 2001 From: Adam Dean <63186174+Crypto2099@users.noreply.github.com> Date: Wed, 8 Nov 2023 17:56:31 -0700 Subject: [PATCH 51/54] Update CIP-XXXX/README.md Co-authored-by: Ryan Williams <44342099+Ryun1@users.noreply.github.com> --- CIP-XXXX/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CIP-XXXX/README.md b/CIP-XXXX/README.md index 01b8253a4c..e341f2830d 100644 --- a/CIP-XXXX/README.md +++ b/CIP-XXXX/README.md @@ -8,7 +8,7 @@ Authors: - Carl - Alex Dochioiu Implementors: -- VESPR Wallet +- VESPR Wallet Discussions: - https://github.com/cardano-foundation/CIPs/pull/546 Created: 2023-06-20 From d1b76d4db6be60fef162b46dbe0fa3d5dc232d70 Mon Sep 17 00:00:00 2001 From: Crypto2099 <63186174+Crypto2099@users.noreply.github.com> Date: Thu, 9 Nov 2023 23:38:19 -0700 Subject: [PATCH 52/54] Changes to CIP-99: * Language edits, additions, and modifications to bring the document in line with community and editor feedback. * Addition of explicit versioning and modification criteria --- {CIP-XXXX => CIP-0099}/README.md | 69 +++++++++++++++++--------------- 1 file changed, 37 insertions(+), 32 deletions(-) rename {CIP-XXXX => CIP-0099}/README.md (87%) diff --git a/CIP-XXXX/README.md b/CIP-0099/README.md similarity index 87% rename from CIP-XXXX/README.md rename to CIP-0099/README.md index e341f2830d..814a008803 100644 --- a/CIP-XXXX/README.md +++ b/CIP-0099/README.md @@ -15,8 +15,6 @@ Created: 2023-06-20 License: CC-BY-4.0 --- -> Current Version: 1 - ## Abstract Since at least 2021 when Cardano entered the Mary Era and implemented Native Assets, projects and creators building on @@ -40,14 +38,6 @@ wallets we can provide a framework for Cardano projects to attend real world eve their Native Assets, and have facts and figures to help support and analyze the impact that their attendance had (Proof of Onboarding). -Furthermore, the aforementioned "paper wallet" technique has many drawbacks including: -* The person(s) responsible for generating the paper wallets at some point have access to the seed phrases generated, leading to a potential security vulnerability -* Projects would need to preload these wallets with funds/tokens; this makes it difficult and/or impossible to reliably know how many of the paper wallets were ever actually claimed -* For those wallets that go forever unclaimed, this essentially creates a permanent "burn" of both Lovelace and the native assets of the project; less than ideal - -We feel that this is necessary as a CIP in order to minimize friction for new projects while maximizing compatibility -across the wide spectrum of Cardano wallets. - ## Specification ### CIP-13 Cardano URI Extensions @@ -74,7 +64,7 @@ Examples: #### ABNF Grammar * For a token claim URI (authority = `claim`), a versioning path, a `faucet_url` and a required `code`. -* Additional query parameters may be provided and should be passed through to the provided `faucet_url` as-is. +* Additional query parameters may be provided and should be passed through to the provided `faucet_url` without modification. ``` cardanourn = "web+cardano:" claimtokenref @@ -88,16 +78,13 @@ claimcode = "code=" text #### Token Claim URI Queries -Token Claim URIs must include a path indicating protocol version and at minimum a `faucet_url` argument pointing to the -faucet hosted and maintained by the project. - **All arguments for Token Claim URIs should be URL-encoded** ***Version 1 URIs*** -Version 1 URIs must include a `faucet_url` and a `code` as required parameters. URIs may include additional arguments to -suit the needs of the project's faucet API. +Version 1 URIs must include a `faucet_url` and a `code` as required parameters. +URIs may include additional arguments to suit the needs of the project's faucet API. #### Handling Token Claim URI Queries @@ -130,7 +117,12 @@ JSON POST Data: The wallet should always send the recipient address in bech32 format. If a particular token faucet implementation wishes to restrict or limit access to their faucet based on staking key or individual wallet address, this should be handled at -the wallet end. +the server end. + +**Supported Addresses** + +* Shelley-era `enterprise` address consisting of only a payment key +* Shelley-era `staking` address consisting of a payment and staking key ##### Note on the `code` field @@ -185,6 +177,7 @@ _Version 1 Examples:_ Get your $HOSKY! ``` + ### Wallet Requests Light wallets that detect and support `web+cardano` URIs as well as mobile wallets who detect either a QR code or other @@ -387,12 +380,30 @@ of 429 or this status response should be considered as a rate limiting response. Implementations should of course be prepared to handle situations where a server is non-responsive for any reason and be prepared to handle any other, non-specified error codes including 500 codes. +### Versioning & Modification Rules + +If there is sufficient justification in the future for modification of this standard to the point that a "Version 2" +would be necessary, those changes MUST be submitted as a new, separate CIP to this repository and follow all applicable +CIP standards for acceptance. Examples of "major" changes that might justify a new version of this CIP include: +fundamentally altering the URI structure, adding or removing a **required** field, or any other non-backwards compatible +changes to the [Process Flow](#process-flow). + +Minor changes for grammar, clarity, or functionality that fall within the scope of "Version 1" of this document may be +made by editing this document directly. Such changes include: grammatical or exposition changes to improve readability +or clarity of communication, improvements to documented code examples, additional or optional server response information, +etc. + ## Rationale: How does this CIP achieve its goals? By creating a well-defined standard for both a CIP-13 URI scheme and the expected API response(s) we can create a framework that both wallets and projects can utilize to encourage and onboard new users into the ecosystem via Native Asset incentive models without needlessly and constantly reinventing the wheel for each product or project. +Furthermore, the aforementioned "paper wallet" technique has many drawbacks including: +* The person(s) responsible for generating the paper wallets at some point have access to the seed phrases generated, leading to a potential security vulnerability +* Projects would need to preload these wallets with funds/tokens; this makes it difficult and/or impossible to reliably know how many of the paper wallets were ever actually claimed +* For those wallets that go forever unclaimed, this essentially creates a permanent "burn" of both Lovelace and the native assets of the project; less than ideal + By utilizing this framework, projects can have accurate, measurable analytics into the success of various real-world marketing and event efforts: Proof of Onboarding. @@ -401,30 +412,24 @@ marketing and event efforts: Proof of Onboarding. ### Acceptance Criteria - [X] Demonstrate a working MVP -- [ ] Open source an MVP example of token faucet server-side code -- [ ] Receive feedback and iterate based on community feedback +- [X] Open source an MVP example of token faucet [server-side code](https://github.com/HOSKYToken/poo-genericClaim) +- [X] Receive feedback and iterate based on community feedback ### Implementation Plan -In order to encourage adoption of this standard the authors commit to execute a functional a minimum viable product +In order to encourage adoption of this standard the authors commit to execute a functional minimum viable proof of concept demonstration in partnership between Adam Dean, HOSKY Token, and VESPR wallet. This real-world implementation should give us important insight on whether the system requires additional modifications or changes. From there we will do our best to engage with other teams and projects in the ecosystem to encourage and support adoption of this standard on a larger scale. -## Acceptance & Implementation Actions - -1. The Proof of Onboarding protocol was demonstrated via MVP during the Edinburgh, Scotland, UK CIP-1694 workshop hosted - by IOG in July 2023. This MVP demonstrated that the protocol works as described in this CIP and the overall feedback - from participants has been positive. This MVP was executed in collaboration with VESPR mobile Cardano wallet, HOSKY - token project, and Adam Dean as the distributor and architect of the specification. - 1. [X] VESPR Mobile Wallet as of the time of this writing has support for Version 1 of the Proof of Onboarding Protocol - and is freely available for the use of any and all projects. - 2. [ ] HOSKY Token project is working on finalizing and releasing a working, open source MVP for the software needed - to be run by the distributing project that will support fungible and non-fungible tokens or any combination thereof. - 3. [ ] Adam Dean is in talks with additional wallet providers to bring P.O.O. support to more platforms as well as - working on open source tooling to facilitate ease of implementation for other projects. +## Implementation Actions + +1. [X] VESPR Mobile Wallet supports the Proof of Onboarding Protocol and is freely available for the use of any and all projects. +2. [X] HOSKY Project has released an open source server-side implementation software that may be used as a proof of concept for any interested projects. +3. [X] Multiple projects at multiple, global events have successfully deployed Proof of Onboarding. +4. [ ] Onboard additional wallet providers, server/service providers, and redemption methods. ## Copyright From 02029004f427ddc05e571312eade5c0ceea3b19b Mon Sep 17 00:00:00 2001 From: Crypto2099 <63186174+Crypto2099@users.noreply.github.com> Date: Tue, 12 Dec 2023 08:40:16 -0700 Subject: [PATCH 53/54] Updates to the implementation plan and acceptance criteria for CIP-99 --- CIP-0099/README.md | 19 ++++++------------- 1 file changed, 6 insertions(+), 13 deletions(-) diff --git a/CIP-0099/README.md b/CIP-0099/README.md index 814a008803..e8a1cbc51e 100644 --- a/CIP-0099/README.md +++ b/CIP-0099/README.md @@ -9,6 +9,7 @@ Authors: - Alex Dochioiu Implementors: - VESPR Wallet +- Yoroi Wallet Discussions: - https://github.com/cardano-foundation/CIPs/pull/546 Created: 2023-06-20 @@ -417,19 +418,11 @@ marketing and event efforts: Proof of Onboarding. ### Implementation Plan -In order to encourage adoption of this standard the authors commit to execute a functional minimum viable -proof of concept demonstration in partnership between Adam Dean, HOSKY Token, and VESPR wallet. This real-world -implementation should give us important insight on whether the system requires additional modifications or changes. - -From there we will do our best to engage with other teams and projects in the ecosystem to encourage and support -adoption of this standard on a larger scale. - -## Implementation Actions - -1. [X] VESPR Mobile Wallet supports the Proof of Onboarding Protocol and is freely available for the use of any and all projects. -2. [X] HOSKY Project has released an open source server-side implementation software that may be used as a proof of concept for any interested projects. -3. [X] Multiple projects at multiple, global events have successfully deployed Proof of Onboarding. -4. [ ] Onboard additional wallet providers, server/service providers, and redemption methods. +- [X] VESPR Mobile Wallet supports the Proof of Onboarding Protocol. +- [X] Yoroi Mobile Wallet supports the Proof of Onboarding Protocol. +- [X] HOSKY Project has released an open source server-side implementation software that may be used as a proof of concept for any interested projects. +- [X] Multiple projects at multiple, global events have successfully deployed Proof of Onboarding. +- [X] Onboard additional wallet providers, server/service providers, and redemption methods. ## Copyright From 90d6d0626f0e36ffb17a8bb78b6632916ab04cd9 Mon Sep 17 00:00:00 2001 From: Crypto2099 <63186174+Crypto2099@users.noreply.github.com> Date: Tue, 12 Dec 2023 10:32:36 -0700 Subject: [PATCH 54/54] Update CIP-99 to active status --- CIP-0099/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CIP-0099/README.md b/CIP-0099/README.md index e8a1cbc51e..4af5c945c0 100644 --- a/CIP-0099/README.md +++ b/CIP-0099/README.md @@ -1,7 +1,7 @@ --- CIP: 99 Title: Proof of Onboarding -Status: Proposed +Status: Active Category: Wallets Authors: - Adam Dean