From a4af173f29d57d269f4e5298da1e0c2774b96084 Mon Sep 17 00:00:00 2001 From: Nils Codes Date: Mon, 5 Aug 2024 20:03:36 -0700 Subject: [PATCH] Correcting a typo in implementation details for error types for CIP-0095 Minor wording improvements to the standard committed alongside. --- CIP-0095/README.md | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/CIP-0095/README.md b/CIP-0095/README.md index 037f57e425..c529c4f534 100644 --- a/CIP-0095/README.md +++ b/CIP-0095/README.md @@ -150,7 +150,7 @@ credential. ### Error Types For the methods described in -[Governance Extension API](#governance-extension-api), we inherent APIError, +[Governance Extension API](#governance-extension-api), we inherit APIError, DataSignError and TxSignError from [CIP-30's Error Types](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0030#error-types). @@ -191,13 +191,13 @@ type APIError { We repurpose this error type from CIP-30, extending it's functionality. We extend the `ProofGeneration` error code to also include cases where DRep secret -key is not available. We also add one new error code `DepreciatedCertificate`. +key is not available. We also add one new error code `DeprecatedCertificate`. ```ts TxSignErrorCode = { ProofGeneration: 1, UserDeclined: 2, - DepreciatedCertificate: 3, + DeprecatedCertificate: 3, }; type TxSignError = { code: TxSignErrorCode; @@ -209,8 +209,8 @@ type TxSignError = { unable to sign the transaction. This is because the wallet does have some of the private keys required. - `UserDeclined` - User declined to sign the transaction. -- `DepreciatedCertificate` - Returned regardless of user consent if the - transaction contains a depreciated certificate. +- `DeprecatedCertificate` - Returned regardless of user consent if the + transaction contains a deprecated certificate. #### [DataSignError](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0030#datasignerror) @@ -377,8 +377,8 @@ should be able to be recognized by supporting wallets. ##### Unsupported Inspection -In the Conway ledger era two certificate types are depreciated `genesis_key_delegation` and `move_instantaneous_rewards_cert`. -If the wallet receives a transaction containing a depreciated certificate it should return a `TxSignError` with an error code of `DepreciatedCertificate`. +In the Conway ledger era two certificate types are deprecated `genesis_key_delegation` and `move_instantaneous_rewards_cert`. +If the wallet receives a transaction containing a deprecated certificate it should return a `TxSignError` with an error code of `DeprecatedCertificate`. | Index | Unsupported Pre-Conway Certificates | | ----- | ----------------------------------- | @@ -407,7 +407,7 @@ endpoint before building the final transaction. | `APIError` | `AccountChange` | `true` or `false` | Returned if wallet has changed account, meaning connection should be reestablished. | | `TxSignError` | `ProofGeneration` | `false` | Returned if user has accepted transaction to sign, but the wallet is unable to sign because it does not have the required key(s). | | `TxSignError` | `UserDeclined` | `true` or `false` | Returned if user has declined to sign the transaction. | -| `TxSignError` | `DepreciatedCertificate` | `true` or `false` | Returned regardless of user consent if the transaction contains a depreciated certificate. | +| `TxSignError` | `DeprecatedCertificate` | `true` or `false` | Returned regardless of user consent if the transaction contains a deprecated certificate. | If `partialSign` is `true`, the wallet only tries to sign what it can. If @@ -662,7 +662,7 @@ cold key setup. Hot and cold keys are not suited for standard light wallets. Genesis key delegation and move instantaneous reward certificates (see in [Shelley spec](https://github.com/IntersectMBO/cardano-ledger/blob/0738804155245062f05e2f355fadd1d16f04cd56/shelley-ma/shelley-ma-test/cddl-files/shelley-ma.cddl#L117#L118)) -are not supported here because they have been depreciated in the Conway ledger +are not supported here because they have been deprecated in the Conway ledger era. Furthermore, due to the lack of accessibility (require access to genesis keys) for these certificates it is extremely unlikely any CIP-30 implementations supported these.