Showing preview only (5,453K chars total). Download the full file or copy to clipboard to get everything.
Repository: cardano-foundation/CIPs
Branch: master
Commit: 5c29bb73d8ae
Files: 430
Total size: 5.1 MB
Directory structure:
gitextract_2tm41wvl/
├── .gitattributes
├── .github/
│ ├── CIP-TEMPLATE.md
│ ├── CPS-TEMPLATE.md
│ ├── CPS-VALIDATION.md
│ ├── schemas/
│ │ └── cps-header.schema.json
│ ├── scripts/
│ │ └── validate-cps.py
│ └── workflows/
│ ├── cip10-validation.yaml
│ └── cps-validation.yaml
├── BiweeklyMeetings/
│ ├── 2020-07-01.md
│ ├── 2020-07-15.md
│ ├── 2020-08-04.md
│ ├── 2020-08-11.md
│ ├── 2020-08-25.md
│ ├── 2020-09-08.md
│ ├── 2020-09-22.md
│ ├── 2020-10-06.md
│ ├── 2020-10-20.md
│ ├── 2020-11-03.md
│ ├── 2020-11-17.md
│ ├── 2020-12-08.md
│ ├── 2021-01-12.md
│ ├── 2021-01-26.md
│ ├── 2021-02-09.md
│ ├── 2021-02-23.md
│ ├── 2021-03-16.md
│ ├── 2021-03-30.md
│ ├── 2021-04-13.md
│ ├── 2021-04-27.md
│ ├── 2021-05-11.md
│ ├── 2021-05-25.md
│ ├── 2021-06-08.md
│ ├── 2021-06-29.md
│ ├── 2021-07-20.md
│ ├── 2021-08-03.md
│ ├── 2021-08-17.md
│ ├── 2021-09-07.md
│ ├── 2021-09-21.md
│ ├── 2021-10-05.md
│ ├── 2021-10-19.md
│ ├── 2021-11-09.md
│ ├── 2021-11-23.md
│ ├── 2021-12-07.md
│ ├── 2021-12-21.md
│ ├── 2022-01-11.md
│ ├── 2022-01-25.md
│ ├── 2022-02-15.md
│ ├── 2022-03-01.md
│ ├── 2022-03-15.md
│ ├── 2022-04-05.md
│ ├── 2022-04-12.md
│ ├── 2022-05-10.md
│ ├── 2022-05-24.md
│ ├── 2022-06-07.md
│ ├── 2022-06-28.md
│ ├── 2022-07-05.md
│ ├── 2022-07-19.md
│ ├── 2022-08-02.md
│ ├── 2022-08-16.md
│ └── 2022-09-06.md
├── CIP-0001/
│ ├── CIP-0001.md
│ └── README.md
├── CIP-0002/
│ ├── CIP-0002.md
│ └── README.md
├── CIP-0003/
│ ├── Byron.md
│ ├── CIP-0003.md
│ ├── Icarus.md
│ ├── Ledger_BitBox02.md
│ └── README.md
├── CIP-0004/
│ ├── CIP-0004.md
│ └── README.md
├── CIP-0005/
│ ├── CIP-0005.md
│ └── README.md
├── CIP-0006/
│ ├── CIP-0006.md
│ ├── README.md
│ └── schema.json
├── CIP-0007/
│ ├── CIP-0007.md
│ ├── README.md
│ └── rewards.php
├── CIP-0008/
│ ├── CIP-0008.md
│ └── README.md
├── CIP-0009/
│ ├── CIP-0009.md
│ └── README.md
├── CIP-0010/
│ ├── CIP-0010.md
│ ├── README.md
│ ├── registry.json
│ └── registry.schema.json
├── CIP-0011/
│ ├── CIP-0011.md
│ └── README.md
├── CIP-0012/
│ ├── CIP-0012.md
│ ├── README.md
│ └── schema.json
├── CIP-0013/
│ ├── CIP-0013.md
│ └── README.md
├── CIP-0014/
│ ├── CIP-0014.md
│ └── README.md
├── CIP-0015/
│ ├── CIP-0015.md
│ ├── README.md
│ ├── schema.cddl
│ └── test-vector.md
├── CIP-0016/
│ ├── CIP-0016.md
│ └── README.md
├── CIP-0017/
│ ├── CIP-0017.json
│ ├── CIP-0017.md
│ └── README.md
├── CIP-0018/
│ ├── CIP-0018.md
│ └── README.md
├── CIP-0019/
│ ├── CIP-0019-byron-addresses.cddl
│ ├── CIP-0019-cardano-addresses.abnf
│ ├── CIP-0019.md
│ └── README.md
├── CIP-0020/
│ ├── CIP-0020.md
│ └── README.md
├── CIP-0021/
│ ├── CIP-0021.md
│ └── README.md
├── CIP-0022/
│ ├── CIP-0022.md
│ └── README.md
├── CIP-0023/
│ ├── CIP-0023.md
│ ├── README.md
│ └── minfees.php
├── CIP-0024/
│ ├── CIP-0024.md
│ └── README.md
├── CIP-0025/
│ ├── CIP-0025.md
│ ├── README.md
│ └── cddl/
│ ├── version_1.cddl
│ └── version_2.cddl
├── CIP-0026/
│ ├── README.md
│ └── schema.json
├── CIP-0027/
│ ├── CIP-0027.md
│ └── README.md
├── CIP-0028/
│ └── README.md
├── CIP-0029/
│ ├── CIP-0029.md
│ ├── README.md
│ ├── phase-1-monetary-scripts.cddl
│ └── phase-1-monetary-scripts.json
├── CIP-0030/
│ ├── README.md
│ └── extensions-register.md
├── CIP-0031/
│ └── README.md
├── CIP-0032/
│ └── README.md
├── CIP-0033/
│ └── README.md
├── CIP-0034/
│ ├── README.md
│ ├── registry.json
│ └── schema.json
├── CIP-0035/
│ └── README.md
├── CIP-0036/
│ ├── README.md
│ ├── schema.cddl
│ └── test-vector.md
├── CIP-0037/
│ └── README.md
├── CIP-0040/
│ └── README.md
├── CIP-0042/
│ └── README.md
├── CIP-0045/
│ └── README.md
├── CIP-0049/
│ └── README.md
├── CIP-0050/
│ └── README.md
├── CIP-0052/
│ ├── README.md
│ └── Tx-spec.md
├── CIP-0054/
│ └── README.md
├── CIP-0055/
│ └── README.md
├── CIP-0057/
│ ├── README.md
│ └── schemas/
│ ├── README.md
│ ├── plutus-blueprint-argument.json
│ ├── plutus-blueprint-parameter.json
│ ├── plutus-blueprint.json
│ ├── plutus-builtin.json
│ └── plutus-data.json
├── CIP-0058/
│ └── README.md
├── CIP-0059/
│ ├── README.md
│ └── feature-table.md
├── CIP-0060/
│ ├── README.md
│ └── cddl/
│ ├── version-1.cddl
│ ├── version-2.cddl
│ └── version-3.cddl
├── CIP-0067/
│ ├── README.md
│ ├── registry.json
│ └── registry.schema.json
├── CIP-0068/
│ ├── README.md
│ ├── extension_boilerplate.md
│ └── ref_impl/
│ ├── README.md
│ ├── offchain.ts
│ └── onchain.hs
├── CIP-0069/
│ └── README.md
├── CIP-0071/
│ ├── README.md
│ └── example/
│ ├── voting.html
│ └── voting.js
├── CIP-0072/
│ ├── README.md
│ ├── version_2.0.0_offchain.json
│ ├── version_2.0.0_onchain.cddl
│ └── version_2.0.0_onchain.json
├── CIP-0074/
│ └── README.md
├── CIP-0075/
│ ├── FairStakepoolRewards.xlsx
│ ├── README.md
│ └── UnsaturatedPledgeBenefitPenalty.xlsx
├── CIP-0080/
│ └── README.md
├── CIP-0082/
│ ├── ImprovedRewardsSchemeParameters.xlsx
│ └── README.md
├── CIP-0083/
│ ├── README.md
│ ├── codesamples/
│ │ ├── democode-BASH.sh
│ │ ├── democode-NODEJS.js
│ │ ├── democode-PHP.php
│ │ ├── democode-WEB.js
│ │ ├── encrypted-message-metadata.json
│ │ └── normal-message-metadata.json
│ └── format.cddl
├── CIP-0084/
│ └── README.md
├── CIP-0085/
│ └── README.md
├── CIP-0086/
│ ├── README.md
│ └── cddl/
│ ├── version_1.cddl
│ └── version_2.cddl
├── CIP-0088/
│ ├── CIPs/
│ │ ├── 0025/
│ │ │ ├── CIP25_v1.cddl
│ │ │ ├── CIP25_v1.json
│ │ │ ├── CIP25_v1.schema.json
│ │ │ └── README.md
│ │ ├── 0026/
│ │ │ ├── CIP26_v1.cddl
│ │ │ ├── CIP26_v1.json
│ │ │ ├── CIP26_v1.schema.json
│ │ │ └── README.md
│ │ ├── 0027/
│ │ │ ├── CIP27_v1.cddl
│ │ │ ├── CIP27_v1.json
│ │ │ ├── CIP27_v1.schema.json
│ │ │ └── README.md
│ │ ├── 0048/
│ │ │ ├── CIP48_v1.cddl
│ │ │ └── README.md
│ │ ├── 0060/
│ │ │ ├── CIP60_v1.cddl
│ │ │ └── README.md
│ │ ├── 0068/
│ │ │ ├── CIP68_v1.cddl
│ │ │ ├── CIP68_v1.json
│ │ │ ├── CIP68_v1.schema.json
│ │ │ └── README.md
│ │ ├── 0086/
│ │ │ ├── CIP86_v1.cddl
│ │ │ └── README.md
│ │ ├── README.md
│ │ ├── common/
│ │ │ ├── CIP88_Master_v1.cddl
│ │ │ ├── CIP88_Master_v2.cddl
│ │ │ ├── CIP88_Master_v2.example.json
│ │ │ ├── README.md
│ │ │ ├── Token-Project-Details_v1.md
│ │ │ ├── token-project-details_v1.cddl
│ │ │ ├── token-project-details_v1.schema.json
│ │ │ └── uri-array.schema.json
│ │ └── template/
│ │ ├── CIPXXXX_v1.cddl
│ │ ├── CIPXXXX_v1.json
│ │ ├── CIPXXXX_v1.schema.json
│ │ └── README.md
│ └── README.md
├── CIP-0089/
│ └── README.md
├── CIP-0091/
│ └── README.md
├── CIP-0093/
│ ├── README.md
│ └── json/
│ └── payload-schema-v1.json
├── CIP-0094/
│ └── README.md
├── CIP-0095/
│ └── README.md
├── CIP-0099/
│ └── README.md
├── CIP-0100/
│ ├── README.md
│ ├── cip-0100.common.jsonld
│ ├── cip-0100.common.schema.json
│ ├── example.body.json
│ ├── example.body.nq
│ ├── example.json
│ └── test-vector.md
├── CIP-0101/
│ └── README.md
├── CIP-0102/
│ └── README.md
├── CIP-0103/
│ └── README.md
├── CIP-0104/
│ └── README.md
├── CIP-0105/
│ ├── README.md
│ ├── test-vectors/
│ │ ├── test-vector-1.md
│ │ ├── test-vector-2.md
│ │ ├── test-vector-3.md
│ │ └── test-vector-4.md
│ └── test-vectors.md
├── CIP-0106/
│ └── README.md
├── CIP-0107/
│ └── README.md
├── CIP-0108/
│ ├── README.md
│ ├── cip-0108.common.jsonld
│ ├── cip-0108.common.schema.json
│ ├── examples/
│ │ ├── no-confidence.body.jsonld
│ │ ├── no-confidence.body.nq
│ │ ├── no-confidence.jsonld
│ │ ├── treasury-withdrawal.body.jsonld
│ │ ├── treasury-withdrawal.body.nq
│ │ └── treasury-withdrawal.jsonld
│ └── test-vector.md
├── CIP-0109/
│ └── README.md
├── CIP-0110/
│ └── README.md
├── CIP-0112/
│ └── README.md
├── CIP-0114/
│ ├── README.md
│ ├── registry.json
│ └── registry.schema.json
├── CIP-0115/
│ └── README.md
├── CIP-0116/
│ ├── README.md
│ ├── cardano-babbage.json
│ ├── cardano-conway.json
│ └── changelog.md
├── CIP-0117/
│ └── README.md
├── CIP-0118/
│ └── README.md
├── CIP-0119/
│ ├── README.md
│ ├── cip-0119.common.jsonld
│ ├── cip-0119.common.schema.json
│ ├── examples/
│ │ └── drep.jsonld
│ └── test-vector.md
├── CIP-0120/
│ ├── README.md
│ ├── examples/
│ │ ├── malicious-consitution/
│ │ │ └── cardano-constitution-5.txt
│ │ └── ryan-consitution/
│ │ └── cardano-constitution-0.txt
│ └── test-vector.md
├── CIP-0121/
│ └── README.md
├── CIP-0122/
│ └── README.md
├── CIP-0123/
│ └── README.md
├── CIP-0124/
│ ├── README.md
│ └── cddl/
│ ├── version_1.cddl
│ └── version_2.cddl
├── CIP-0127/
│ └── README.md
├── CIP-0128/
│ └── README.md
├── CIP-0129/
│ └── README.md
├── CIP-0132/
│ └── README.md
├── CIP-0133/
│ └── README.md
├── CIP-0134/
│ └── README.md
├── CIP-0135/
│ └── README.md
├── CIP-0136/
│ ├── README.md
│ ├── cip-136.common.jsonld
│ ├── cip-136.common.schema.json
│ ├── examples/
│ │ ├── parameter-change-abstain.body.jsonld
│ │ ├── parameter-change-abstain.body.nq
│ │ ├── parameter-change-abstain.jsonld
│ │ ├── treasury-withdrawal-unconstitutional.body.jsonld
│ │ ├── treasury-withdrawal-unconstitutional.body.nq
│ │ └── treasury-withdrawal-unconstitutional.jsonld
│ └── test-vector.md
├── CIP-0137/
│ └── README.md
├── CIP-0138/
│ └── README.md
├── CIP-0139/
│ ├── Query_Layer_API_Comparison.md
│ ├── README.md
│ ├── cip-0144.md
│ ├── endpoints.md
│ ├── json-rpc.json
│ ├── open-api.json
│ ├── query-layer.json
│ └── ts-api.md
├── CIP-0140/
│ ├── .gitignore
│ ├── README.md
│ ├── flake.nix
│ └── peras.agda-lib
├── CIP-0141/
│ └── README.md
├── CIP-0142/
│ └── README.md
├── CIP-0143/
│ └── README.md
├── CIP-0146/
│ └── README.md
├── CIP-0149/
│ └── README.md
├── CIP-0150/
│ ├── README.md
│ └── stats.json
├── CIP-0151/
│ ├── CIP88_Master_v2.cddl
│ ├── CIP88_Master_v2.example.json
│ └── README.md
├── CIP-0152/
│ └── README.md
├── CIP-0153/
│ └── README.md
├── CIP-0155/
│ ├── README.md
│ ├── registry.json
│ └── registry.schema.json
├── CIP-0156/
│ └── README.md
├── CIP-0158/
│ └── README.md
├── CIP-0159/
│ └── README.md
├── CIP-0160/
│ └── README.md
├── CIP-0161/
│ ├── README.md
│ └── graph/
│ ├── NhandNa.py
│ ├── extended_error_series_corrected.csv
│ ├── scenario-cost-cross-thresholds.py
│ ├── scenario_cost_praos_vs_phalanx-full-scenarios.py
│ ├── scenario_cost_praos_vs_phalanx.py
│ ├── settlement-time-phalanx.py
│ ├── settlement-time-praos.py
│ ├── settlement-time-without-grinding.py
│ └── vdf_benches.py
├── CIP-0162/
│ └── README.md
├── CIP-0163/
│ └── README.md
├── CIP-0164/
│ ├── README.md
│ └── SUMMARY.md
├── CIP-0165/
│ ├── README.md
│ ├── format/
│ │ ├── format.ksy
│ │ └── scls_file.html
│ └── namespaces/
│ ├── README.md
│ ├── blocks_v0.cddl
│ ├── gov_committee_v0.cddl
│ ├── gov_constitution_v0.cddl
│ ├── gov_pparams_v0.cddl
│ ├── gov_proposals_v0.cddl
│ ├── nonces_v0.cddl
│ ├── pool_stake_v0.cddl
│ ├── snapshots_v0.cddl
│ └── utxo_v0.cddl
├── CIP-0167/
│ └── README.md
├── CIP-0170/
│ ├── README.md
│ ├── example-credential-chain.cesr
│ ├── example-revocation-event.cesr
│ ├── version_1.cddl
│ ├── version_1.json
│ └── vlei-cardano-metadata-signer-credential.json
├── CIP-0171/
│ └── README.md
├── CIP-0176/
│ └── README.md
├── CIP-0381/
│ └── README.md
├── CIP-1694/
│ ├── README.fr.md
│ └── README.md
├── CIP-1852/
│ ├── CIP-1852.md
│ └── README.md
├── CIP-1853/
│ ├── CIP-1853.md
│ └── README.md
├── CIP-1854/
│ ├── CIP-1854.md
│ └── README.md
├── CIP-1855/
│ ├── CIP-1855.md
│ └── README.md
├── CIP-9999/
│ └── README.md
├── CODE_OF_CONDUCT.md
├── CONTRIBUTING
├── CPS-0003/
│ └── README.md
├── CPS-0005/
│ └── README.md
├── CPS-0007/
│ └── README.md
├── CPS-0008/
│ └── README.md
├── CPS-0009/
│ └── README.md
├── CPS-0010/
│ └── README.md
├── CPS-0011/
│ └── README.md
├── CPS-0012/
│ └── README.md
├── CPS-0013/
│ └── README.md
├── CPS-0014/
│ └── README.md
├── CPS-0016/
│ └── README.md
├── CPS-0017/
│ └── README.md
├── CPS-0018/
│ └── README.md
├── CPS-0020/
│ └── README.md
├── CPS-0021/
│ ├── CPD/
│ │ ├── README.md
│ │ └── graph/
│ │ ├── forking_probabilities.py
│ │ ├── mixing_probabilities.py
│ │ ├── scenario_cost-graph.py
│ │ ├── scenario_cpu_graph.py
│ │ └── window0_graph.py
│ └── README.md
├── CPS-0022/
│ └── README.md
├── LICENSE
└── README.md
================================================
FILE CONTENTS
================================================
================================================
FILE: .gitattributes
================================================
* linguist-vendored
*.md linguist-vendored=false
================================================
FILE: .github/CIP-TEMPLATE.md
================================================
---
CIP: ?
Title: ?
Category: ?
Status: Proposed
Authors:
- John Doe <john.doe@email.domain>
Implementors: []
Discussions:
- https://github.com/cardano-foundation/CIPs/pull/?
Created: YYYY-MM-DD
License: CC-BY-4.0
---
<!-- Existing categories:
- Meta | For meta-CIPs which typically serves another category or group of categories.
- Wallets | For standardisation across wallets (hardware, full-node or light).
- Tokens | About tokens (fungible or non-fungible) and minting policies in general.
- Metadata | For proposals around metadata (on-chain or off-chain).
- Tools | A broad category for ecosystem tools not falling into any other category.
- Plutus | Changes or additions to Plutus
- Ledger | For proposals regarding the Cardano ledger (including Reward Sharing Schemes)
- Consensus | For proposals affecting implementations of the Cardano Consensus layer and algorithms
- Network | Specifications and implementations of Cardano's network protocols and applications
-->
## Abstract
<!-- A short (\~200 word) description of the proposed solution and the technical issue being addressed. -->
## Motivation: why is this CIP necessary?
<!-- A clear explanation that introduces the reason for a proposal, its use cases and stakeholders. If the CIP changes an established design then it must outline design issues that motivate a rework. For complex proposals, authors must write a Cardano Problem Statement (CPS) as defined in CIP-9999 and link to it as the `Motivation`. -->
## Specification
<!-- The technical specification should describe the proposed improvement in sufficient technical detail. In particular, it should provide enough information that an implementation can be performed solely on the basis of the design in the CIP. This is necessary to facilitate multiple, interoperable implementations. This must include how the CIP should be versioned, if not covered under an optional Versioning main heading. If a proposal defines structure of on-chain data it must include a CDDL schema in its specification.-->
## Rationale: how does this CIP achieve its goals?
<!-- The rationale fleshes out the specification by describing what motivated the design and what led to particular design decisions. It should describe alternate designs considered and related work. The rationale should provide evidence of consensus within the community and discuss significant objections or concerns raised during the discussion.
It must also explain how the proposal affects the backward compatibility of existing solutions when applicable. If the proposal responds to a CPS, the 'Rationale' section should explain how it addresses the CPS, and answer any questions that the CPS poses for potential solutions.
-->
## Path to Active
### Acceptance Criteria
<!-- Describes what are the acceptance criteria whereby a proposal becomes 'Active' -->
<!-- For core categories (Ledger, Plutus, Network, Consensus) the following SHOULD be included:
- [ ] Implementation present within block producing nodes used by 80%+ of stake
-->
### Implementation Plan
<!-- A plan to meet those criteria or `N/A` if an implementation plan is not applicable. -->
<!-- OPTIONAL SECTIONS: see CIP-0001 > Document > Structure table -->
## Copyright
<!-- The CIP must be explicitly licensed under acceptable copyright terms. Uncomment the license you wish to use (delete the other one) and ensure it matches the License field in the header.
If AI/LLMs were used in the creation of the copyright text, the author may choose to include a disclaimer to describe their application within the proposal.
-->
<!-- This CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode). -->
<!-- This CIP is licensed under [Apache-2.0](http://www.apache.org/licenses/LICENSE-2.0). -->
================================================
FILE: .github/CPS-TEMPLATE.md
================================================
---
CPS: ?
Title: ?
Category: ?
Status: Open
Authors:
- John Doe <john.doe@email.domain>
Proposed Solutions: []
Discussions:
- Original pull request: https://github.com/cardano-foundation/CIPs/pull/?
Created: YYYY-MM-DD
License: CC-BY-4.0
---
<!-- Existing categories:
- Meta | For meta-CIPs which typically serves another category or group of categories.
- Wallets | For standardisation across wallets (hardware, full-node or light).
- Tokens | About tokens (fungible or non-fungible) and minting policies in general.
- Metadata | For proposals around metadata (on-chain or off-chain).
- Tools | A broad category for ecosystem tools not falling into any other category.
- Plutus | Changes or additions to Plutus
- Ledger | For proposals regarding the Cardano ledger (including Reward Sharing Schemes)
- Consensus | For proposals affecting implementations of the Cardano Consensus layer and algorithms
- Network | Specifications and implementations of Cardano's network protocols and applications
-->
## Abstract
<!-- A short (\~200 word) description of the target goals and the technical obstacles to those goals. -->
## Problem
<!-- A more elaborate description of the problem and its context. This section should explain what motivates the writing of the CPS document. -->
## Use Cases
<!-- A concrete set of examples written from a user's perspective, describing what and why they are trying to do. When they exist, this section should give a sense of the current alternatives and highlight why they are not suitable. -->
## Goals
<!-- A list of goals and non-goals a project is pursuing, ranked by importance. These goals should help understand the design space for the solution and what the underlying project is ultimately trying to achieve.
Goals may also contain requirements for the project. For example, they may include anything from a deadline to a budget (in terms of complexity or time) to security concerns.
Finally, goals may also serve as evaluation metrics to assess how good a proposed solution is. -->
## Open Questions
<!-- A set of questions to which any proposed solution should find an answer. Questions should help guide solutions design by highlighting some foreseen vulnerabilities or design flaws. Solutions in the form of CIP should thereby include these questions as part of their 'Rationale' section and provide an argued answer to each. -->
<!-- OPTIONAL SECTIONS: see CIP-9999 > Specification > CPS > Structure table -->
## Copyright
<!-- The CPS must be explicitly licensed under acceptable copyright terms. Uncomment the license you wish to use (delete the other one) and ensure it matches the License field in the header.
If AI/LLMs were used in the creation of the copyright text, the author may choose to include a disclaimer to describe their application within the proposal.
-->
<!-- This CPS is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode). -->
<!-- This CPS is licensed under [Apache-2.0](http://www.apache.org/licenses/LICENSE-2.0). -->
================================================
FILE: .github/CPS-VALIDATION.md
================================================
# CPS Validation Rules
This document describes all validation rules applied to Cardano Problem Statement (CPS) documents.
These validations are to be ran automatically via Github workflow using [`/scripts/validate-cps.py`](./scripts/validate-cps.py).
These attempt to codify the guidance described within [CIP-9999 | Cardano Problem Statements](../CIP-9999/README.md).
## File-Level Validations
| Validation | Description |
| ---------- | ----------- |
| File path | Must be in a `CPS-*` directory |
| Line endings | Must use UNIX line endings (LF), not Windows (CRLF) or old Mac (CR) |
| Frontmatter | Must have valid YAML frontmatter between `---` delimiters |
| No H1 headings | H1 (`#`) headings are not allowed in the document body |
## Header Field Validations
All 9 fields are **required**,
must appear in order,
and no extra fields are allowed.
| Field | Order | Validation Rules |
| ----- | ----- | ---------------- |
| **CPS** | 1 | Positive integer (`1`, `42`) or `?`/`??`/etc. for unassigned. No leading zeros. |
| **Title** | 2 | 1-100 characters, no backticks (`` ` ``) |
| **Category** | 3 | One of: `Meta`, `Wallets`, `Tokens`, `Metadata`, `Tools`, `Plutus`, `Ledger`, `Consensus`, `Network`, `?` |
| **Status** | 4 | `Open`, `Solved`, or `Inactive` (optionally with reason, e.g., `Inactive (Superseded)`) |
| **Authors** | 5 | Non-empty list, each entry: `Name <email>` |
| **Proposed Solutions** | 6 | List (can be empty), each entry: `Label: URL` |
| **Discussions** | 7 | Non-empty list, each entry: `Label: URL` |
| **Created** | 8 | Date in `YYYY-MM-DD` format |
| **License** | 9 | `CC-BY-4.0` or `Apache-2.0` |
## CIP Label Validation
For the **Proposed Solutions** and **Discussions** fields,
when an entry label matches the `CIP-NNNN` pattern,
extra validation applies:
| Rule | Description |
| ---- | ----------- |
| GitHub URL required | Must be `https://github.com/cardano-foundation/CIPs/...` |
| Valid URL types | `/pull/NNN` (PR) or `/tree/{branch}/CIP-NNNN` or `/blob/{branch}/CIP-NNNN` (merged) |
| `?` suffix for PRs | `CIP-0030?` required when linking to a pull request (candidate) |
| No `?` for merged | `CIP-0030` (without `?`) required when linking to a merged CIP |
Non-CIP labels (e.g., `Forum Post`, `Pull Request`) are allowed with any valid URL.
## Required Sections (H2 Headers)
The following sections must exist in this order with **exact capitalization**.
**No other H2 sections are allowed** except the optional sections listed below.
| Order | Section |
| ----- | ------- |
| 1 | `Abstract` |
| 2 | `Problem` |
| 3 | `Use Cases` |
| 4 | `Goals` |
| 5 | `Open Questions` |
| 6 | `Copyright` |
## Optional Sections
The following sections are allowed with exact capitalization.
They **must** appear after `Open Questions` and before `Copyright`:
- `References`
- `Appendices`
- `Acknowledgments` / `Acknowledgements`
Optional sections appearing before any required section (other than `Copyright`) will cause validation to fail.
================================================
FILE: .github/schemas/cps-header.schema.json
================================================
{
"$schema": "http://json-schema.org/draft-07/schema#",
"$id": "https://github.com/cardano-foundation/CIPs/.github/schemas/cps-header.schema.json",
"title": "CPS Header Schema",
"description": "JSON Schema for validating YAML frontmatter headers in Cardano Problem Statements (CPSs)",
"type": "object",
"required": [
"CPS",
"Title",
"Category",
"Status",
"Authors",
"Proposed Solutions",
"Discussions",
"Created",
"License"
],
"properties": {
"CPS": {
"description": "The CPS number (without leading 0), or one or more '?' before number has been assigned",
"oneOf": [
{
"type": "string",
"pattern": "^\\?+$"
},
{
"type": "integer",
"minimum": 1
},
{
"type": "string",
"pattern": "^[1-9]\\d*$"
}
]
},
"Title": {
"description": "A succinct and descriptive title. Don't use backticks (`) in titles since they disrupt formatting in other contexts. Must be less than 100 characters.",
"type": "string",
"minLength": 1,
"maxLength": 100,
"not": {
"pattern": "`"
}
},
"Category": {
"description": "One of the editorially accepted categories covering one area of the ecosystem",
"type": "string",
"enum": [
"Meta",
"Wallets",
"Tokens",
"Metadata",
"Tools",
"Plutus",
"Ledger",
"Consensus",
"Network",
"?"
]
},
"Status": {
"description": "Status of the CPS: Open, Solved, or Inactive (with optional reason)",
"type": "string",
"pattern": "^(Open|Solved|Inactive(?:\\s+\\(.*\\))?)$"
},
"Authors": {
"description": "A list of authors' real names and email addresses (e.g. John Doe <john.doe@email.domain>)",
"type": "array",
"minItems": 1,
"items": {
"type": "string",
"pattern": "^.+\\s+<.+>$",
"description": "Author entry in format: Name <email@domain.com>"
}
},
"Proposed Solutions": {
"description": "A list of CIPs addressing the problem, if any. Can be an empty array []. Each entry is 'Label: URL'. When label is CIP-NNNN, URL must be a GitHub CIPs repo link; use '?' suffix for PRs (candidates).",
"type": "array",
"items": {
"oneOf": [
{
"type": "string",
"minLength": 1,
"pattern": "^.+:\\s+https?://.+$",
"description": "Entry in format: 'Label: URL'"
},
{
"type": "object",
"minProperties": 1,
"maxProperties": 1,
"additionalProperties": {
"type": "string",
"format": "uri"
},
"description": "Dictionary format: {'Label': 'URL'}"
}
]
}
},
"Discussions": {
"description": "A list of links where major technical discussions regarding this CPS happened. Must include a link to the pull request that created the CPS. Each entry must have a label followed by a colon and URL. Can be a string 'Label: URL' or a dictionary {'Label': 'URL'}.",
"type": "array",
"minItems": 1,
"items": {
"oneOf": [
{
"type": "string",
"pattern": "^.+:\\s+https?://.+$",
"description": "Entry in format: 'Label: URL'"
},
{
"type": "object",
"minProperties": 1,
"maxProperties": 1,
"additionalProperties": {
"type": "string",
"format": "uri"
},
"description": "Dictionary format: {'Label': 'URL'}"
}
]
}
},
"Created": {
"description": "Date created on, in ISO 8601 (YYYY-MM-DD) format",
"type": "string",
"pattern": "^\\d{4}-\\d{2}-\\d{2}$",
"format": "date"
},
"License": {
"description": "Abbreviation of an approved license",
"type": "string",
"enum": [
"CC-BY-4.0",
"Apache-2.0"
]
}
},
"additionalProperties": false
}
================================================
FILE: .github/scripts/validate-cps.py
================================================
#!/usr/bin/env python3
"""
Validation script for CPS README.md files.
Validates YAML headers and required sections.
"""
import sys
import re
import json
import yaml
from pathlib import Path
from typing import Dict, List, Set, Tuple, Optional
try:
import jsonschema
except ImportError:
print("Error: jsonschema library is required. Install it with: pip install jsonschema", file=sys.stderr)
sys.exit(1)
# Required fields for CPS headers (in required order)
CPS_REQUIRED_FIELDS_ORDER = [
'CPS', 'Title', 'Category', 'Status', 'Authors',
'Proposed Solutions', 'Discussions', 'Created', 'License'
]
CPS_REQUIRED_FIELDS = set(CPS_REQUIRED_FIELDS_ORDER)
# Required sections (H2 headers) in required order
CPS_REQUIRED_SECTIONS_ORDER = [
'Abstract',
'Problem',
'Use Cases',
'Goals',
'Open Questions',
'Copyright'
]
CPS_REQUIRED_SECTIONS = set(CPS_REQUIRED_SECTIONS_ORDER)
# Optional H2 sections (allowed but not required)
# These should appear after the required sections, before Copyright
CPS_OPTIONAL_SECTIONS = {
'References',
'Appendices',
'Acknowledgments',
'Acknowledgements'
}
# Load CPS header schema
SCHEMA_PATH = Path(__file__).parent.parent / 'schemas' / 'cps-header.schema.json'
with open(SCHEMA_PATH, 'r', encoding='utf-8') as f:
CPS_HEADER_SCHEMA = json.load(f)
def parse_frontmatter(content: str) -> Tuple[Optional[Dict], Optional[str], Optional[List[str]]]:
"""Parse YAML frontmatter from markdown content.
Returns:
Tuple of (frontmatter_dict, remaining_content, raw_lines) or (None, content, None) if no frontmatter
"""
# Check for frontmatter delimiters - must start with ---
if not content.startswith('---'):
return None, content, None
# Find the closing delimiter (--- on its own line)
# Split on '\n---\n' or '\n---' at end of content
lines = content.split('\n')
if lines[0] != '---':
return None, content, None
# Find the closing ---
end_idx = None
for i in range(1, len(lines)):
if lines[i] == '---':
end_idx = i
break
if end_idx is None:
return None, content, None
# Extract frontmatter (lines between the two --- markers)
frontmatter_lines = lines[1:end_idx]
# Preprocess: quote standalone '?' values (YAML interprets '?' as explicit key indicator)
processed_lines = []
for line in frontmatter_lines:
# Match lines like "CPS: ?" or "Category: ?" and quote the ?
if re.match(r'^[A-Za-z][A-Za-z ]*:\s+\?+\s*$', line):
line = re.sub(r':\s+(\?+)\s*$', r': "\1"', line)
processed_lines.append(line)
frontmatter_text = '\n'.join(processed_lines)
# Extract remaining content (everything after the closing ---)
remaining_lines = lines[end_idx + 1:]
remaining_content = '\n'.join(remaining_lines)
try:
frontmatter = yaml.safe_load(frontmatter_text)
if frontmatter is None:
return None, content, None
return frontmatter, remaining_content, frontmatter_lines
except yaml.YAMLError as e:
return None, content, None
except ValueError as e:
# Catches invalid date values that YAML tries to parse (e.g., month 13)
return None, content, None
def extract_h2_headers(content: str) -> List[str]:
"""Extract all H2 headers (##) from markdown content."""
h2_pattern = r'^##\s+(.+)$'
headers = []
for line in content.split('\n'):
match = re.match(h2_pattern, line)
if match:
headers.append(match.group(1).strip())
return headers
def extract_h1_headers(content: str) -> List[str]:
"""Extract all H1 headers (#) from markdown content."""
h1_pattern = r'^#\s+(.+)$'
headers = []
for line in content.split('\n'):
match = re.match(h1_pattern, line)
if match:
headers.append(match.group(1).strip())
return headers
def validate_line_endings(file_path: Path) -> List[str]:
"""Validate that file uses UNIX line endings (LF, not CRLF).
Returns:
List of error messages (empty if valid)
"""
errors = []
try:
# Read file in binary mode to check line endings
with open(file_path, 'rb') as f:
content_bytes = f.read()
# Check for CRLF (\r\n) - Windows line endings
if b'\r\n' in content_bytes:
errors.append("File uses Windows line endings (CRLF). Use UNIX line endings (LF) instead.")
# Check for standalone \r without \n (old Mac line endings)
# Replace CRLF first, then check for remaining CR
content_without_crlf = content_bytes.replace(b'\r\n', b'')
if b'\r' in content_without_crlf:
errors.append("File uses old Mac line endings (CR). Use UNIX line endings (LF) instead.")
except Exception as e:
errors.append(f"Error checking line endings: {e}")
return errors
def validate_no_h1_headings(content: str) -> List[str]:
"""Validate that no H1 headings are present in the document.
Returns:
List of error messages (empty if valid)
"""
errors = []
h1_headers = extract_h1_headers(content)
if h1_headers:
errors.append(f"H1 headings are not allowed. Found: {', '.join(h1_headers)}")
return errors
def _validate_field_order(frontmatter: Dict) -> List[str]:
"""Validate that header fields appear in the correct order.
Returns:
List of error messages (empty if valid)
"""
errors = []
# Get the actual order of fields in the frontmatter
actual_fields = list(frontmatter.keys())
# Filter to only known required fields (ignore any extra fields for order check)
actual_required = [f for f in actual_fields if f in CPS_REQUIRED_FIELDS]
# Build expected order based on which required fields are present
expected_order = [f for f in CPS_REQUIRED_FIELDS_ORDER if f in actual_required]
if actual_required != expected_order:
errors.append(
f"Header fields are not in the correct order. "
f"Expected: {', '.join(expected_order)}. "
f"Got: {', '.join(actual_required)}"
)
return errors
def validate_header(frontmatter: Dict) -> List[str]:
"""Validate the YAML frontmatter header for CPSs.
Returns:
List of error messages (empty if valid)
"""
errors = []
# Validate field order
errors.extend(_validate_field_order(frontmatter))
# Validate header fields using JSON Schema
try:
# Convert date objects to strings for schema validation
# JSON Schema expects dates as strings, but PyYAML may parse them as date objects
# Also normalize dictionary entries in lists to strings (YAML parses "Label: URL" as dict)
frontmatter_for_schema = {}
for key, value in frontmatter.items():
if key == 'Created' and hasattr(value, 'isoformat'):
# Handle date objects from PyYAML (datetime.date or datetime.datetime)
frontmatter_for_schema[key] = value.isoformat()
elif key in ('Proposed Solutions', 'Discussions') and isinstance(value, list):
# Convert dictionary entries to string format "Label: URL"
normalized_list = []
for item in value:
if isinstance(item, dict):
# Convert dict like {'Label': 'URL'} to string 'Label: URL'
if len(item) == 1:
label, url = next(iter(item.items()))
normalized_list.append(f"{label}: {url}")
else:
# Multiple keys - join them
normalized_list.append(": ".join(f"{k}: {v}" for k, v in item.items()))
elif isinstance(item, str):
normalized_list.append(item)
else:
normalized_list.append(str(item))
frontmatter_for_schema[key] = normalized_list
else:
frontmatter_for_schema[key] = value
jsonschema.validate(instance=frontmatter_for_schema, schema=CPS_HEADER_SCHEMA)
except jsonschema.ValidationError as e:
# Format JSON Schema validation errors in a user-friendly way
error_path = '.'.join(str(p) for p in e.path) if e.path else 'root'
errors.append(f"Header validation error at '{error_path}': {e.message}")
except jsonschema.SchemaError as e:
errors.append(f"Schema error: {e.message}")
# Validate CIP label semantic rules (label/URL relationship)
if 'Proposed Solutions' in frontmatter:
errors.extend(_validate_cip_label_entries(frontmatter['Proposed Solutions'], 'Proposed Solutions'))
if 'Discussions' in frontmatter:
errors.extend(_validate_cip_label_entries(frontmatter['Discussions'], 'Discussions'))
return errors
def _validate_cip_label_entries(entries: list, field_name: str) -> List[str]:
"""Validate semantic rules for entries with CIP labels.
When a label matches CIP-NNNN pattern:
- URL must be a GitHub CIPs repository link (PR or merged CIP)
- Pull request URLs require '?' suffix on the CIP number (candidate)
- Merged CIP URLs must NOT have '?' suffix
Other labels are allowed with any valid URL.
Args:
entries: List of label-URL entries
field_name: Name of the field for error messages
Returns:
List of error messages (empty if valid)
"""
errors = []
if not isinstance(entries, list):
return errors
cip_label_pattern = re.compile(r'^(CIP-\d+)(\?)?$')
pr_pattern = re.compile(r'https://github\.com/cardano-foundation/CIPs/pull/\d+')
merged_pattern = re.compile(r'https://github\.com/cardano-foundation/CIPs/(tree|blob)/[^/]+/CIP-\d+')
github_cips_pattern = re.compile(r'^https://github\.com/cardano-foundation/CIPs/(pull/\d+|tree/[^/]+/CIP-\d+|blob/[^/]+/CIP-\d+)')
for i, entry in enumerate(entries):
# Normalize to label and URL
if isinstance(entry, dict) and len(entry) == 1:
label, url = next(iter(entry.items()))
elif isinstance(entry, str):
# Parse "Label: URL" format
match = re.match(r'^([^:]+):\s+(.+)$', entry)
if not match:
continue
label, url = match.groups()
else:
continue
label = label.strip()
url = url.strip()
# Check if label matches CIP pattern - only then apply extra validation
label_match = cip_label_pattern.match(label)
if not label_match:
continue # Non-CIP labels are allowed with any URL
cip_number = label_match.group(1)
has_question_mark = label_match.group(2) == '?'
# For CIP labels, URL must be a GitHub CIPs repository link
if not github_cips_pattern.match(url):
errors.append(
f"'{field_name}' entry {i+1}: CIP label '{label}' requires a GitHub CIPs repository URL "
f"(pull request or merged CIP). Got: {url}"
)
continue
is_pr = pr_pattern.search(url) is not None
is_merged = merged_pattern.search(url) is not None
if is_pr and not has_question_mark:
errors.append(
f"'{field_name}' entry {i+1}: Pull request URL requires '?' suffix on CIP number "
f"(use '{cip_number}?' instead of '{cip_number}' to indicate candidate status)"
)
elif is_merged and has_question_mark:
errors.append(
f"'{field_name}' entry {i+1}: Merged CIP should not have '?' suffix "
f"(use '{cip_number}' instead of '{cip_number}?' since this CIP is merged)"
)
return errors
def validate_sections(content: str) -> List[str]:
"""Validate required sections exist at H2 level for CPSs.
Returns:
List of error messages (empty if valid)
"""
errors = []
h2_headers = extract_h2_headers(content)
found_sections = set(h2_headers)
# Normalize headers to lowercase for case-insensitive comparison
found_sections_lower = {h.lower() for h in found_sections}
required_sections_lower = {h.lower() for h in CPS_REQUIRED_SECTIONS}
optional_sections_lower = {h.lower() for h in CPS_OPTIONAL_SECTIONS}
# Check for missing required sections (case-insensitive)
missing_sections_lower = required_sections_lower - found_sections_lower
if missing_sections_lower:
# Map back to original case from required_sections for error message
missing_sections = {orig for orig in CPS_REQUIRED_SECTIONS
if orig.lower() in missing_sections_lower}
errors.append(f"Missing required sections: {', '.join(sorted(missing_sections))}")
# Check for unknown sections (not in required or optional)
allowed_sections_lower = required_sections_lower | optional_sections_lower
for header in h2_headers:
if header.lower() not in allowed_sections_lower:
errors.append(f"Unknown section: '{header}'. Only required and optional sections are allowed.")
# Build a mapping from lowercase to expected capitalization
expected_capitalization = {}
for section in CPS_REQUIRED_SECTIONS:
expected_capitalization[section.lower()] = section
for section in CPS_OPTIONAL_SECTIONS:
expected_capitalization[section.lower()] = section
# Check for incorrect capitalization
for header in h2_headers:
header_lower = header.lower()
if header_lower in expected_capitalization:
expected = expected_capitalization[header_lower]
if header != expected:
errors.append(f"Section '{header}' has incorrect capitalization. Expected: '{expected}'")
# Check section order
# Map found headers to their canonical names (for order comparison)
canonical_headers = []
for header in h2_headers:
header_lower = header.lower()
if header_lower in expected_capitalization:
canonical_headers.append(expected_capitalization[header_lower])
else:
canonical_headers.append(header) # Keep unknown headers as-is
# Extract just the required sections in the order they appear
found_required_order = [h for h in canonical_headers if h in CPS_REQUIRED_SECTIONS]
# Build expected order based on which required sections are present
expected_required_order = [s for s in CPS_REQUIRED_SECTIONS_ORDER if s in found_required_order]
if found_required_order != expected_required_order:
errors.append(
f"Sections are not in the correct order. "
f"Expected: {', '.join(expected_required_order)}. "
f"Got: {', '.join(found_required_order)}"
)
# Check that optional sections appear only between "Open Questions" and "Copyright"
# Optional sections must not appear before any required section except Copyright
optional_sections_normalized = {s.lower() for s in CPS_OPTIONAL_SECTIONS}
required_before_optional = [s for s in CPS_REQUIRED_SECTIONS_ORDER if s != 'Copyright']
for i, header in enumerate(canonical_headers):
header_lower = header.lower()
if header_lower in optional_sections_normalized:
# This is an optional section - check what comes after it
for j in range(i + 1, len(canonical_headers)):
following_header = canonical_headers[j]
# If a required section (other than Copyright) follows an optional section, that's an error
if following_header in required_before_optional:
errors.append(
f"Optional section '{header}' appears before required section '{following_header}'. "
f"Optional sections must appear after 'Open Questions' and before 'Copyright'."
)
break
return errors
def is_cps_file(file_path: Path) -> bool:
"""Check if file path indicates a CPS document."""
path_str = str(file_path)
# Normalize path separators and check for CPS- pattern
# Handles both absolute (/CPS-123/) and relative (CPS-123/) paths
# Also handles Windows paths (CPS-123\README.md)
normalized_path = path_str.replace('\\', '/')
# Check for CPS- pattern (with or without leading slash)
return bool(re.search(r'(^|/)CPS-', normalized_path, re.IGNORECASE))
def validate_file(file_path: Path) -> Tuple[bool, List[str]]:
"""Validate a single CPS README.md file.
Returns:
Tuple of (is_valid, list_of_errors)
"""
errors = []
# Check if this is a CPS file
if not is_cps_file(file_path):
return False, [f"File path does not indicate a CPS document: {file_path}"]
# Validate line endings (must check raw file bytes)
line_ending_errors = validate_line_endings(file_path)
errors.extend(line_ending_errors)
# Read file content
try:
content = file_path.read_text(encoding='utf-8')
except Exception as e:
return False, [f"Error reading file: {e}"]
# Parse frontmatter
frontmatter, remaining_content, raw_lines = parse_frontmatter(content)
if frontmatter is None:
errors.append("Missing or invalid YAML frontmatter (must start with '---' and end with '---')")
return False, errors
# Check for leading zeros in CPS field (YAML loses this information)
if raw_lines:
for line in raw_lines:
if re.match(r'^CPS:\s+0\d+', line):
errors.append("CPS number must not have leading zeros")
break
# Validate header
header_errors = validate_header(frontmatter)
errors.extend(header_errors)
# Validate no H1 headings
h1_errors = validate_no_h1_headings(remaining_content)
errors.extend(h1_errors)
# Validate sections
section_errors = validate_sections(remaining_content)
errors.extend(section_errors)
is_valid = len(errors) == 0
return is_valid, errors
def main():
"""Main entry point for the validation script."""
if len(sys.argv) < 2:
print("Usage: validate-cps.py <file1> [file2] ...", file=sys.stderr)
sys.exit(1)
files_to_validate = [Path(f) for f in sys.argv[1:]]
all_valid = True
all_errors = []
for file_path in files_to_validate:
if not file_path.exists():
print(f"Error: File not found: {file_path}", file=sys.stderr)
all_valid = False
continue
is_valid, errors = validate_file(file_path)
if not is_valid:
all_valid = False
print(f"\nValidation failed for {file_path}:", file=sys.stderr)
for error in errors:
print(f" - {error}", file=sys.stderr)
all_errors.append((file_path, errors))
if not all_valid:
print(f"\nValidation failed for {len(all_errors)} file(s)", file=sys.stderr)
sys.exit(1)
print(f"\nAll {len(files_to_validate)} file(s) passed validation", file=sys.stderr)
sys.exit(0)
if __name__ == '__main__':
main()
================================================
FILE: .github/workflows/cip10-validation.yaml
================================================
name: CIP-10 - Validate Registry JSON on Pull Request
on:
pull_request:
paths:
- 'CIP-0010/registry.json'
jobs:
approve: # Pre-approval step
runs-on: ubuntu-latest
steps:
- name: Approve
run: echo For security reasons, all pull requests need to be approved first before running any automated CI.
validate-json:
runs-on: ubuntu-latest
steps:
- name: Checkout repository
uses: actions/checkout@v3
- name: Set up Node.js
uses: actions/setup-node@v3
with:
node-version: '21'
- name: Install dependencies
run: npm install ajv-cli
- name: Validate JSON against schema
run: npx ajv validate -s CIP-0010/registry.schema.json -d CIP-0010/registry.json > /dev/null
================================================
FILE: .github/workflows/cps-validation.yaml
================================================
name: CPS Validation
on:
pull_request:
paths:
- 'CPS*/README.md'
- 'cps*/README.md'
workflow_dispatch:
inputs:
pr_number:
description: 'PR number to validate'
required: true
type: string
jobs:
validate:
runs-on: ubuntu-latest
steps:
- name: Checkout repository
uses: actions/checkout@v4
with:
fetch-depth: 0
- name: Fetch PR branch
if: github.event_name == 'workflow_dispatch'
run: |
git fetch origin pull/${{ github.event.inputs.pr_number }}/head:pr-branch
git checkout pr-branch
- name: Set up Python
uses: actions/setup-python@v5
with:
python-version: '3.11'
- name: Install dependencies
run: |
pip install pyyaml jsonschema
- name: Get CPS files to validate
id: get-files
run: |
if [ "${{ github.event_name }}" = "workflow_dispatch" ]; then
# Manual run: diff PR branch against master
FILES=$(git diff --name-only --diff-filter=ACMR origin/master...HEAD | grep -iE '^CPS-[^/]+/README\.md$' || true)
else
# PR trigger: diff against base branch
FILES=$(git diff --name-only --diff-filter=ACMR HEAD~1 HEAD | grep -iE '^CPS-[^/]+/README\.md$' || true)
fi
if [ -z "$FILES" ]; then
echo "No CPS README.md files to validate"
echo "has_files=false" >> $GITHUB_OUTPUT
exit 0
fi
# Convert newlines to spaces for passing as arguments
FILES_SPACE=$(echo "$FILES" | tr '\n' ' ')
echo "has_files=true" >> $GITHUB_OUTPUT
echo "files=$FILES_SPACE" >> $GITHUB_OUTPUT
- name: Validate CPS files
if: steps.get-files.outputs.has_files == 'true'
run: |
FILES="${{ steps.get-files.outputs.files }}"
echo "Validating CPS files: $FILES"
python3 .github/scripts/validate-cps.py $FILES
================================================
FILE: BiweeklyMeetings/2020-07-01.md
================================================
**Table of Contents:**
- [Summary](#summary)
- [Editors Meeting Flow](#editors-meeting-flow)
- [July 1 2020 notes](#july-1-2020-notes)
* [Triage](#triage)
* [Last Check](#last-check)
* [Review](#review)
+ [CIP2](#cip2)
* [Discussions](#discussions)
* [Close](#close)
- [Extra](#extra)
* [Current CIPs in the CIP repository and their status](#current-cips-in-the-cip-repository-and-their-status)
* [CIP creation process as a UML Diagram](#cip-creation-process-as-a-uml-diagram)
* [Understanding CIPs further](#understanding-cips-further)
## Summary
Rough writeup of 7/1/20 Editors meeting notes taken during that day's CIP meeting, to increase transparency and dialogue with the community regarding proposed changes, implementations and considerations.
<sub>_Notes might contain errors or miss pieces - call out issues as needed_
</sub>
## Editors Meeting Flow
- [x] **Triage/Review**: Some CIPs might fall out of grace or not get updated, a CIP that hasn’t seen activity for 3 months should be checked on, and appropriate action taken. Ex: did any of the recent changes obsolete current CIPs? Consider ‘Active’ -> ‘Obsolete’ transitions..
- [x] **Last Check**: Review of the PRIOR meetings Decisions - if no objection, apply change (effectively a two week lag from decision to action, as a grace period)
- [x] **New CIPs Review**: CIPs up for review should be looked over collectively, with discussion where needed. (on top of the asynchronous reviews)
PR -> ‘Draft’: Needs format + approval.
‘Draft’ -> ‘Proposed’: Needs a PLAN towards Active + implementation.
‘Proposed’ -> ‘Active’: Objective criteria as laid out observed, and consensus agreeing.
- [x] **Current Discussions**: What the current CIPs discussions are on social media / forums / Discord.
- [x] **Close**: Recap of actions taken and decisions. List the CIPs that are due for review. Distribution of the minutes via mailing list.
## July 1 2020 notes
**Attending**: (Duncan, Sebastien, Frederic, Matthias)
### Triage
- Nothing to review yet!
### Last Check
=> **Action**: - merge PR (CIP1 copy tweak)
### Review
#### CIP2
> (Discussions already took place in that PR comments!)
> A few items to change for the current CIP2 PR
> Missing the fee - Description is wrong… Should the termination condition incorporate the idea that some inputs might be too small to spend? Or should it be part of the available condition UTXO or Ignored (a choice)
Add a query about if the algorithm is clear in presence of a min UTXO output.. (was it considered for Byron?)
> Possibly: remove “for Cardano” from the title
### Discussions
- Side conversations for how the Wallet work for Shelley key derivations (currently on the Adrestia user guide, might be worth moving to the CIP).
- Other Qs regarding transaction Metadata (format allows for wide-range)...
- (could/should be freeform?)
- Describe a way of versioning metadata?
- Need some agreement on namespace else it might lead to confusion.
- CIP notes should be merged in post meeting in the CIP Repo - will be fleshed out in the coming week.
### Close
- CIP1 Copy tweak PR - to merge asap.
- “Coin Selection Algorithms” PR agreed on, to be merged in as CIP2 ‘Draft’ if no issues next meeting (7/15)
- Meeting notes (these) to be added to the CIP repo itself for visibility on process.
(Close)
---
## Extra
### Current CIPs in the CIP repository and their status
|# |Title | Status |
| ----------------- |:----------------|:-------------------- |
| 1 | [CIP Process](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0001) | Active |
:bulb: - For more details about Statuses, refer to [CIP1](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0001).
### CIP creation process as a Sequence Diagram
_"Alice has a Cardano idea she'd like to build more formally":_
### Understanding CIPs further
[](https://www.youtube.com/watch?v=q7U10EfqXJw)
[](https://www.youtube.com/watch?v=dnw7k7VKVyo)
================================================
FILE: BiweeklyMeetings/2020-07-15.md
================================================
**Table of Contents:**
- [Summary](#summary)
- [Editors Meeting Flow](#editors-meeting-flow)
- [July 15 2020 notes](#july-15-2020-notes)
* [Triage](#triage)
* [Last Check](#last-check)
* [Review](#review)
+ [CIP5](#cip5)
* [Discussions](#discussions)
* [Close](#close)
- [Extra](#extra)
* [Current CIPs in the CIP repository and their status](#current-cips-in-the-cip-repository-and-their-status)
* [CIP creation process as a UML Diagram](#cip-creation-process-as-a-uml-diagram)
* [Understanding CIPs further](#understanding-cips-further)
## Summary
Rough writeup of 7/15/20 Editors meeting notes taken during that day's CIP meeting, to increase transparency and dialogue with the community regarding proposed changes, implementations and considerations.
<sub>_Notes might contain errors or miss pieces - call out issues as needed_
</sub>
## Editors Meeting Flow
- [x] **Triage/Review**: Some CIPs might fall out of grace or not get updated, a CIP that hasn’t seen activity for 3 months should be checked on, and appropriate action taken. Ex: did any of the recent changes obsolete current CIPs? Consider ‘Active’ -> ‘Obsolete’ transitions..
- [x] **Last Check**: Review of the PRIOR meetings Decisions - if no objection, apply change (effectively a two week lag from decision to action, as a grace period)
- [x] **New CIPs Review**: CIPs up for review should be looked over collectively, with discussion where needed. (on top of the asynchronous reviews)
PR -> ‘Draft’: Needs format + approval.
‘Draft’ -> ‘Proposed’: Needs a PLAN towards Active + implementation.
‘Proposed’ -> ‘Active’: Objective criteria as laid out observed, and consensus agreeing.
- [x] **Current Discussions**: What the current CIPs discussions are on social media / forums / Discord.
- [x] **Close**: Recap of actions taken and decisions. List the CIPs that are due for review. Distribution of the minutes via mailing list.
## July 15 2020 notes
**Attending**: (Duncan, Sebastien, Frederic, ~~Matthias~~) + Eystein (guest)
### Triage
- Still issues with the multi-review.
- Need to add meeting notes to the repo.
- Merge pr (copy tweak on CIP1).
### Last Check
=> **Action**: - merge pr (CIP2 - “Coin Selection” - DRAFT)
### Review
#### CIP5
>**Sebastian** - Happy with all.
Need to resolve that Cardano Wallet and possibly CLI uses this list, but Haskell-Shelley Rust codebase doesn’t use this, and uses diff prefixes… and this should be the main issue there. I would have to go in there and fix the prefixes themselves.
>**D**: Reviewing the prefixes right now.
>**S**: We have diff prefixes for mainnet and testnet. Which is duplicating the header payload.
>**D**: It duplicates it but in an error checking way. If you need to render… The bit in the payload tells you that. And if mismatch, then you can address. In some sense, it duplicates and makes it visible to the user that they are dealing with a testnet address.
>**Eystein** - would be good to have multiple iteration prefixes per testnet
>**D**-> poor form - distinguishing is broken down. Addr is to prevent people from spending real money to testnet .. You don’t have that problem from testnet to testnet.
>**S**: “Diff addr type in Shelley” Vs. Jormungandr. The concern is that diff address types might be confusing to ppl. So for Daedalus and Yoroi we decided to only support grp addresses.
For Haskell-Shelley, we will have the same issue - so most likely those other addr. types will be hidden behind some flags of sorts.
>**D**: That’ll likely be up to the wallet itself to figure out which type to use.
>**E**: I don’t care if automated - I can see a usecase for both…
>**D**: The distinction between the internal addr struct is just not important to regular users. It’s probably more confusing to highlight those as 10 different combinations.. Of staking, base, ptr…
All of these can be by key or by script. Do we want to distinguish clearly? Is that helpful? Can it be actively un-helpful?
Because in the end they are all payment addresses.
>**S**: I think that would be a mess with users. I am more about enterprise vs. base. Because they all in a sense have their own chain - BIP44 sense? If you generate your addr for a single key. … this has to be displayed differently.
(..)
>**D**: Privacy in a wallet is the same as BTC or ETC - Under Matthias / Sebastien scheme, it’s easy to see they belong together. You only get privacy at the wallet account level.
3 ways a pmt addr can refer to a stake. And therefore have stake or not:
Null (short)
Ptr (short)
Base (long)
>**S**: Since all generated, the wallet will have to render … you’d have diff pages. Ex - a page for external addr page. Would need a way to toggle the rendering - to switch between base and ptr.
>**D**: There should be a default - it would never as standard mode for users do null staking..
>**S**: after the initial release the wallet would show default release.
>**D**: Wallet should not confuse users by presenting too many options… If easier to display short addr, should be simplified.
>**D**: It’s a disc to have with Matthias - for Seb. (+Darko)
Should we lump all Txs under one prefix?
>**S** - I am not yet convinced about the addr prefix. But not concerned.
>**D**: You don’t have to add the addr. if the wallet takes care of it for you.
>**S**: Every addr. in Yoroi could display what type it is… would deal with the combinations. Screen space was dedicated for that but could be freed if bech32 impl.
>**D**: Not majorly important.
### Discussions
- Pool operators are thinking about a “Standardizing” CIP.
- Opening up meetings visibility to the public.
- Internal requests to consider CIP exploration re: Address management (for 100ks of i.e. exchanges).
- Eystein as first guest - Reinvite an option to connect with community (Want to carefully open up meetings to public… at first 1-2 spots, later more).
_Eystein had a good talk he did at the Cardano Summit in July - he understands governance / the need for CIPs._
### Close
- **CIP5** as Draft OK to merge - will be iterated on.
- **CIP2** Merged delayed till next meeting to round up last Qs.
(missing - current minor PR qs - ex: where and how to store meeting notes)
(Close)
---
## Extra
### Current CIPs in the CIP repository and their status
|# |Title | Status |
| ----------------- |:----------------|:-------------------- |
| 1 | [CIP Process](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0001) | Active |
:bulb: - For more details about Statuses, refer to [CIP1](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0001).
### CIP creation process as a Sequence Diagram
_"Alice has a Cardano idea she'd like to build more formally":_
### Understanding CIPs further
[](https://www.youtube.com/watch?v=q7U10EfqXJw)
[](https://www.youtube.com/watch?v=dnw7k7VKVyo)
================================================
FILE: BiweeklyMeetings/2020-08-04.md
================================================
**Table of Contents:**
- [Summary](#summary)
- [Editors Meeting Flow](#editors-meeting-flow)
- [Aug 4 2020 notes](#august-4-2020-notes)
* [Triage](#triage)
* [Last Check](#last-check)
* [Review](#review)
* [Discussions](#discussions)
* [Close](#close)
- [Extra](#extra)
* [Current CIPs in the CIP repository and their status](#current-cips-in-the-cip-repository-and-their-status)
* [CIP creation process as a UML Diagram](#cip-creation-process-as-a-uml-diagram)
* [Understanding CIPs further](#understanding-cips-further)
## Summary
Rough writeup of 8/4/20 Editors meeting notes taken during that day's CIP meeting, to increase transparency and dialogue with the community regarding proposed changes, implementations and considerations.
<sub>_Notes might contain errors or miss pieces - call out issues as needed_
</sub>
## Editors Meeting Flow
- [x] **Triage/Review**: Some CIPs might fall out of grace or not get updated, a CIP that hasn’t seen activity for 3 months should be checked on, and appropriate action taken. Ex: did any of the recent changes obsolete current CIPs? Consider ‘Active’ -> ‘Obsolete’ transitions..
- [x] **Last Check**: Review of the PRIOR meetings Decisions - if no objection, apply change (effectively a two week lag from decision to action, as a grace period)
- [x] **New CIPs Review**: CIPs up for review should be looked over collectively, with discussion where needed. (on top of the asynchronous reviews)
PR -> ‘Draft’: Needs format + approval.
‘Draft’ -> ‘Proposed’: Needs a PLAN towards Active + implementation.
‘Proposed’ -> ‘Active’: Objective criteria as laid out observed, and consensus agreeing.
- [x] **Current Discussions**: What the current CIPs discussions are on social media / forums / Discord.
- [x] **Close**: Recap of actions taken and decisions. List the CIPs that are due for review. Distribution of the minutes via mailing list.
## Aug 4 2020 notes
**Attending**: (Duncan, Frederic, ~~Matthias~~, ~~Sebastien~~) + Ben (CF)
### Triage
- Merge pr (copy tweak on CIP1)
### Last Check
- Merge CIP2 (Draft)
- Merge CIP5 (Draft)
### Review
N/A
### Discussions
*(short discussion centered around new PRs - from the past two weeks - that should move forward as 'Draft' - we shouldn't be trying to have perfect PRs, rather enable reworking as 'Draft')*
- Setup a CIP for protocol parameters (Ask Romain? Kevin / Alex)
- Review Meeting #2 notes in next meeting to continue threads
- Need to upload some version of the notes in the CIP repository for visibility
- should CIP 2&5 add License file and readme?
### Close
- **CIP1** copy tweaks merged
- **CIP2** merged as 'Draft'
- **CIP5** merged as 'Draft'
(Close)
---
## Extra
### Current CIPs in the CIP repository and their status
|# |Title | Status |
| ----------------- |:----------------|:-------------------- |
| 1 | [CIP Process](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0001) | Active |
| 2 | [Coin Selection Algorithms for Cardano](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0002) | Draft |
| 5 | [Common Bech32 Prefixes](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0005) | Draft |
:bulb: - For more details about Statuses, refer to [CIP1](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0001).
### CIP creation process as a Sequence Diagram
_"Alice has a Cardano idea she'd like to build more formally":_
### Understanding CIPs further
[](https://www.youtube.com/watch?v=q7U10EfqXJw)
[](https://www.youtube.com/watch?v=dnw7k7VKVyo)
================================================
FILE: BiweeklyMeetings/2020-08-11.md
================================================
**Table of Contents:**
- [Summary](#summary)
- [Editors Meeting Flow](#editors-meeting-flow)
- [August 11 2020 notes](#-11-2020-notes)
* [Triage](#triage)
* [Last Check](#last-check)
* [Review](#review)
+ [CIP5](#cip5)
+ [CIP4](#cip4)
+ [CIP3](#cip3)
* [Discussions](#discussions)
* [Close](#close)
- [Extra](#extra)
* [Current CIPs in the CIP repository and their status](#current-cips-in-the-cip-repository-and-their-status)
* [CIP creation process as a UML Diagram](#cip-creation-process-as-a-uml-diagram)
* [Understanding CIPs further](#understanding-cips-further)
## Summary
Rough writeup of 8/11/20 Editors meeting notes taken during that day's CIP meeting, to increase transparency and dialogue with the community regarding proposed changes, implementations and considerations.
<sub>_Notes might contain errors or miss pieces - call out issues as needed_
</sub>
## Editors Meeting Flow
- [x] **Triage/Review**: Some CIPs might fall out of grace or not get updated, a CIP that hasn’t seen activity for 3 months should be checked on, and appropriate action taken. Ex: did any of the recent changes obsolete current CIPs? Consider ‘Active’ -> ‘Obsolete’ transitions..
- [x] **Last Check**: Review of the PRIOR meetings Decisions - if no objection, apply change (effectively a two week lag from decision to action, as a grace period)
- [x] **New CIPs Review**: CIPs up for review should be looked over collectively, with discussion where needed. (on top of the asynchronous reviews)
PR -> ‘Draft’: Needs format + approval.
‘Draft’ -> ‘Proposed’: Needs a PLAN towards Active + implementation.
‘Proposed’ -> ‘Active’: Objective criteria as laid out observed, and consensus agreeing.
- [x] **Current Discussions**: What the current CIPs discussions are on social media / forums / Discord.
- [x] **Close**: Recap of actions taken and decisions. List the CIPs that are due for review. Distribution of the minutes via mailing list.
## August 11 2020 notes
**Attending**: (~~Duncan~~, Frederic, Matthias, Sebastien) + Ben (CF)
### Triage
N/A
### Last Check
N/A
### Review
#### CIP5
> **Matthias** - Needs to be finalized a bit more to be moved to “Proposed”. The internals of addresses are not really relevant for users. I don’t see why having diff. prefixes would help. Except for Advanced users.
> **M** - It actually *could* go to “Proposed” right now - it doesn’t prevent us from doing updates. The set of problems we are working on is changing, so having revisions on CIP makes sense. The issue of updating a CIP beyond a final setup would be done through an update.
> **Sebastien** - it would be nice to have a separate prefix for others… We can modify stuff after once that is settled… and that is fine as we will have to change things.
#### CIP4
> **S** - Needs test vectors - should be quick. The Wallet checksum should be merged, it just got shipped.
In CIP4 there are 2 versions - the Shelley Account is using the new format - everything is working - we have a javascript inmplemetation. We are hopefully going to release as Yoroi extension. Would be nice to have it merged. My understanding is that both teams are fine - it makes more sense, it’s more secure - it’s a bit more complicated.
> **M** - I see you changed a lot more since I looked at it - will try to review it and move forward.
> **S** - That CIP will also be used by Ergo - it will be a multichain standard functionally (used by Ergo).
> **S** - I have a few examples in Emurgo test library - I don’t have the pictures… hope that’s ok.
#### CIP3
> Still need more work before merging into Draft.
### Discussions
1. **M** - Change the README to the CIPx file… (change CIP1 content to reflect the structure) -> **Frederic**
2. Proper License files needed for CIP5 & CIP2 -> **M**
3. Some Stake pool operators think CIPs are a bit too complex - tried to convince Markus to write up a CIP to no avail... This seems like another way of not being heard. So StakePools wrote their own version. Some community members feel this isn’t fair… It might be good to push into a CIP? CIP engagement is still a bit too Silo’d - process could be *more* open. Would need someone in the community to “engage”. We could upload videos or notes in a more public way.
4. **M** - If ppl don’t want to write CIPs we can’t really force them. Since this is coming from the CF/IOHK/Emurgo - it frightens a bit the community. Having ppl from the community involved as CIP Editors might help?
5. **Ben** - (Different possible flows for CIP Editorship, to be continued next meeting)
### Close
**TODO** Add license files to CIP5 & CIP2 (**Matthias**)
**TODO** Change Format of CIPs (in CIP 1) to have the structures of CIPs change to readme.md (instead CIPx.md) (**Frederic**)
(Close)
---
## Extra
### Current CIPs in the CIP repository and their status
|# |Title | Status |
| ----------------- |:----------------|:-------------------- |
| 1 | [CIP Process](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0001) | Active |
| 2 | [Coin Selection Algorithms for Cardano](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0002) | Draft |
| 5 | [Common Bech32 Prefixes](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0005) | Draft |
:bulb: - For more details about Statuses, refer to [CIP1](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0001).
### CIP creation process as a Sequence Diagram
_"Alice has a Cardano idea she'd like to build more formally":_
### Understanding CIPs further
[](https://www.youtube.com/watch?v=q7U10EfqXJw)
[](https://www.youtube.com/watch?v=dnw7k7VKVyo)
================================================
FILE: BiweeklyMeetings/2020-08-25.md
================================================
**Table of Contents:**
- [Summary](#summary)
- [Editors Meeting Flow](#editors-meeting-flow)
- [August 25 2020 notes](#august-25-2020-notes)
* [Triage](#triage)
* [Last Check](#last-check)
* [Review](#review)
+ [CIP2](#cip2)
+ [CIP5](#cip5)
* [Discussions](#discussions)
* [Close](#close)
- [Extra](#extra)
* [Current CIPs in the CIP repository and their status](#current-cips-in-the-cip-repository-and-their-status)
* [CIP creation process as a UML Diagram](#cip-creation-process-as-a-uml-diagram)
* [Understanding CIPs further](#understanding-cips-further)
## Summary
Rough writeup of 8/25/20 Editors meeting notes taken during that day's CIP meeting, to increase transparency and dialogue with the community regarding proposed changes, implementations and considerations.
<sub>_Notes might contain errors or miss pieces - call out issues as needed_
</sub>
## Editors Meeting Flow
- [x] **Triage/Review**: Some CIPs might fall out of grace or not get updated, a CIP that hasn’t seen activity for 3 months should be checked on, and appropriate action taken. Ex: did any of the recent changes obsolete current CIPs? Consider ‘Active’ -> ‘Obsolete’ transitions..
- [x] **Last Check**: Review of the PRIOR meetings Decisions - if no objection, apply change (effectively a two week lag from decision to action, as a grace period)
- [x] **New CIPs Review**: CIPs up for review should be looked over collectively, with discussion where needed. (on top of the asynchronous reviews)
PR -> ‘Draft’: Needs format + approval.
‘Draft’ -> ‘Proposed’: Needs a PLAN towards Active + implementation.
‘Proposed’ -> ‘Active’: Objective criteria as laid out observed, and consensus agreeing.
- [x] **Current Discussions**: What the current CIPs discussions are on social media / forums / Discord.
- [x] **Close**: Recap of actions taken and decisions. List the CIPs that are due for review. Distribution of the minutes via mailing list.
## August 25 2020 notes
**Attending**: (Duncan, Frederic, Matthias, ~~Sebastien~~) + Ben (CF)
### Triage
N/A
### Last Check
Merging in meeting notes to publicize the process itself
### Review
#### CIP2
> **Matthias** - This is a lengthy CIP and will benefit from a more thorough review.
#### CIP5
> Discussion around currencies. Cardano does multi-asset by having a bundle. Address and tokens two separate entities.
**Matthias** propose to remove addr in prefixes to keep consistency. Remove reference.
**Duncan** will get rid of addr_bootstrap because it's confusing (can render a Byron address bip32 style).
### Discussions
1. **Frederic** brings up CIP stake pool meta-data concerns in the community. A discussion over badges for ITN pools, a CIP could be written? Just because a CIP is 'Active' doesn't mean implemented.
2. **F** suggests prioritizing community PRs towards 'Draft' to exemplify community ideas make it through. Ex: "Extended Metadata" [PR](https://github.com/cardano-foundation/CIPs/pull/15/files).
3. **D** (discussing back and forth with SMASH server) mentions the metadata isn't on-chain or at least no link back to on-chain except through the URL.
4. **M**: For CIP structure, would prefer moving to only using the 'Readme.md' file and cutting the 'Cip#.md' file.
**F**: Aligned - some delays might come due to auto-generated site.
**M**: Not a blocker. Github keeps track of all.
### Close
**TODO** Invite community members to upcoming meeting (**Frederic**)
**On Hold** Change Format of CIPs (in CIP 1) (instead CIPx.md)
**TODO** Probe IOG for promised parameter CIP (**Frederic**)
(Close)
---
## Extra
### Current CIPs in the CIP repository and their status
|# |Title | Status |
| ----------------- |:----------------|:-------------------- |
| 1 | [CIP Process](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0001) | Active |
| 2 | [Coin Selection Algorithms for Cardano](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0002) | Draft |
| 5 | [Common Bech32 Prefixes](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0005) | Draft |
:bulb: - For more details about Statuses, refer to [CIP1](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0001).
### CIP creation process as a Sequence Diagram
_"Alice has a Cardano idea she'd like to build more formally":_
### Understanding CIPs further
[](https://www.youtube.com/watch?v=q7U10EfqXJw)
[](https://www.youtube.com/watch?v=dnw7k7VKVyo)
================================================
FILE: BiweeklyMeetings/2020-09-08.md
================================================
**Table of Contents:**
- [Summary](#summary)
- [Editors Meeting Flow](#editors-meeting-flow)
- [September 08 2020 notes](#september-08-2020-notes)
* [Triage](#triage)
* [Last Check](#last-check)
* [Review](#review)
+ [Extended Metadata](#Extended-Metadata)
+ [Curve Pledge Benefit](#Curve-Pledge-Benefit)
* [Discussions](#discussions)
* [Close](#close)
- [Extra](#extra)
* [Current CIPs in the CIP repository and their status](#current-cips-in-the-cip-repository-and-their-status)
* [CIP creation process as a UML Diagram](#cip-creation-process-as-a-uml-diagram)
* [Understanding CIPs further](#understanding-cips-further)
## Summary
Rough writeup of 9/8/20 Editors meeting notes taken during that day's CIP meeting, to increase transparency and dialogue with the community regarding proposed changes, implementations and considerations.
<sub>_Notes might contain errors or miss pieces - call out issues as needed_
</sub>
## Editors Meeting Flow
- [x] **Triage/Review**: Some CIPs might fall out of grace or not get updated, a CIP that hasn’t seen activity for 3 months should be checked on, and appropriate action taken. Ex: did any of the recent changes obsolete current CIPs? Consider ‘Active’ -> ‘Obsolete’ transitions..
- [x] **Last Check**: Review of the PRIOR meetings Decisions - if no objection, apply change (effectively a two week lag from decision to action, as a grace period)
- [x] **New CIPs Review**: CIPs up for review should be looked over collectively, with discussion where needed. (on top of the asynchronous reviews)
PR -> ‘Draft’: Needs format + approval.
‘Draft’ -> ‘Proposed’: Needs a PLAN towards Active + implementation.
‘Proposed’ -> ‘Active’: Objective criteria as laid out observed, and consensus agreeing.
- [x] **Current Discussions**: What the current CIPs discussions are on social media / forums / Discord.
- [x] **Close**: Recap of actions taken and decisions. List the CIPs that are due for review. Distribution of the minutes via mailing list.
## September 08 2020 notes
**Attending**: (Duncan, Frederic, ~Matthias~, Sebastien) + Steve(CF) + Shawn, Markus, Mike (PR Authors)
### Triage
N/A
### Last Check
N/A
### Review
#### Extended Metadata
([PR](https://github.com/cardano-foundation/CIPs/pull/15) - potential CIP6)
#### Curve Pledge Benefit
([PR](https://github.com/cardano-foundation/CIPs/pull/12) - potential CIP7)
### Discussions
N/A - not enough time due to extended reviews.
### Close
**On Hold** Change Format of CIPs (in CIP1) (instead CIPx.md) - awaiting Frontend fix to auto-gen site
---
## Extra
### Current CIPs in the CIP repository and their status
|# |Title | Status |
| ----------------- |:----------------|:-------------------- |
| 1 | [CIP Process](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0001) | Active |
| 2 | [Coin Selection Algorithms for Cardano](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0002) | Draft |
| 5 | [Common Bech32 Prefixes](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0005) | Draft |
:bulb: - For more details about Statuses, refer to [CIP1](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0001).
### CIP creation process as a Sequence Diagram
_"Alice has a Cardano idea she'd like to build more formally":_
### Understanding CIPs further
[](https://www.youtube.com/watch?v=q7U10EfqXJw)
[](https://www.youtube.com/watch?v=dnw7k7VKVyo)
================================================
FILE: BiweeklyMeetings/2020-09-22.md
================================================
**Table of Contents:**
- [Summary](#summary)
- [Editors Meeting Flow](#editors-meeting-flow)
- [September 22 2020 notes](#september-22-2020-notes)
* [Triage](#triage)
* [Last Check](#last-check)
* [Review](#review)
+ [Curve Pledge Benefit](#Curve-Pledge-Benefit)
+ [Extended Metadata](#Extended-Metadata)
* [Discussions](#discussions)
* [Close](#close)
- [Extra](#extra)
* [Current CIPs in the CIP repository and their status](#current-cips-in-the-cip-repository-and-their-status)
* [CIP creation process as a UML Diagram](#cip-creation-process-as-a-uml-diagram)
* [Understanding CIPs further](#understanding-cips-further)
## Summary
Rough writeup of 9/22/20 Editors meeting notes taken during that day's CIP meeting, to increase transparency and dialogue with the community regarding proposed changes, implementations and considerations.
<sub>_Notes might contain errors or miss pieces - call out issues as needed_
</sub>
## Editors Meeting Flow
- [x] **Triage/Review**: Some CIPs might fall out of grace or not get updated, a CIP that hasn’t seen activity for 3 months should be checked on, and appropriate action taken. Ex: did any of the recent changes obsolete current CIPs? Consider ‘Active’ -> ‘Obsolete’ transitions..
- [x] **Last Check**: Review of the PRIOR meetings Decisions - if no objection, apply change (effectively a two week lag from decision to action, as a grace period)
- [x] **New CIPs Review**: CIPs up for review should be looked over collectively, with discussion where needed. (on top of the asynchronous reviews)
PR -> ‘Draft’: Needs format + approval.
‘Draft’ -> ‘Proposed’: Needs a PLAN towards Active + implementation.
‘Proposed’ -> ‘Active’: Objective criteria as laid out observed, and consensus agreeing.
- [x] **Current Discussions**: What the current CIPs discussions are on social media / forums / Discord.
- [x] **Close**: Recap of actions taken and decisions. List the CIPs that are due for review. Distribution of the minutes via mailing list.
## September 22 2020 notes
**Attending**: (Duncan, Frederic, Matthias, Sebastien) + Jeremy(CF) + Shawn, Markus (PR Authors) + Collin (IOG)
### Triage
N/A
### Last Check
N/A
### Review
#### Curve Pledge Benefit
([PR](https://github.com/cardano-foundation/CIPs/pull/12) - potential CIP7)
**Shawn** - (recap) Current pledging incentive mechanism linear setup is less than optimal for <1M ada. The superwhale end of the spectrum provides about 30% benefit for ppl able to pledge their own pool to saturation - By using a curve pledge mechanism instead of a linear one we can incentivise in a better way (for smaller folks/pools).
(see graphs in the PR)
**Duncan** - Not as simple, incentive folks are exploring all scenarios
**Collin** - We don’t want for the high end to be the clear winner.I like the form of the solution - almost a smile shape. Not aligned with all but a solid proposal as-is.
**Duncan** - This has been raised internally with IOHK researchers already - they weren’t so positive about it, but have been looking at it.
**Colin** - They are in the long term equilibrium - but right now the linear isn’t working.
**Duncan** - It was mentioned it should probably be skewed in the opposite direction..
**Colin** - if you can get the delegation bonus as a big holder, you’re much better off splitting into tiny pools right now
**Duncan** - Researchers are aware of that - which direction it goes non-linear might cause issues.
At no point should it be non-rewarding to add more stake to your pool.
**Markus** - What about a ‘S’ curve mentioned by Charles?
**Colin** - (Showing example graph) = M * (1/p) + N * p
**Markus** - There are some good points or reasons that this can help
What are the drawbacks or downsides based on a linear and non-linear approach?
**Frederic** - The conversation about the solution can take place once the CIP has been setup as Draft, suggest we move to merge the PR and let conversation take place beyond.
***[Move to MERGE as CIP7]*** (all agree)
#### Extended Metadata
([PR](https://github.com/cardano-foundation/CIPs/pull/15) - potential CIP6)
**Markus** - Recap on the conversation since last meeting:
Last week Shawn gave some good proposals about a more standardized and well-thought structure for extended metadata.Need a response from ADA Pools as they implemented something without following the Script process.
**Duncan** - Is there the right balance of features to include? You can try to get consensus amongst operators. Mechanism is important to consider, the other attributes can be decided at a later state.
**Markus** - We reconsider the maximum size of the metadata file. All other things which are not very crucial, going out quick and sending messages to SPOs can be done in a different way. A potential Metadata proposal should involve security risks considerations, not just adding fields.
**Duncan** - Reasonable to say we can add a few extra fields for metadata and limit the total data size to 1,000 bytes... If security is important, we could have a design Field extended with a URL, have a verification key (public key) which is signed for extended metadata. This means you don’t have to use the same key as your pool code key...
**Markus** - Need to speak with more pool operators to see the approaches out there. I Will reach out and follow up.
**Frederic** - Might be good to have competing views and discuss publicly, Multiple CIPs can propose different implementation proposals.
**Markus** - Some pools have large teams and need metadata. “Cardano Scan” does a good job but is not known. Yoroi and Daedalus have uses of course too.
**Duncan**- Frontend Daedalus Devs might be concerned about showing metadata when there is a security concern. RSS feed is a good example of a feature in the extended markdown
**Sebastien** - The pool selection UI is outsourced for Yoroi. One feature we do care about is RSS feed, we would embed this into the UI. The existing proposal doesn't really talk about RSS feed into extended metadata.
**Matthias** - Re: Daedalus frontend considerations - hard to say, there is a need for the data. Onchain there is not a limit of data. It's enforced by the software (SMASH). we can increase this.
Can show the hash is on chain, there is a security risk and no way to verify you are looking at the right data. Having a key and hashing that the data is accurate is a good way.
**Duncan** - If there is a key in the first MD level to sign the second MD level, this is a good mechanism. You could use HTTPS, could have a fingerprint of the hashed certificate, cant be replaced by any other certificates.
**Markus** - Will look at rewriting the existing PR with assistance of ADApools and reframe/rework proposal next.
**Frederic** - Can be discussed in comments of the CIP as draft maybe? (would like to bring it in)
**Duncan** - People should discuss with others in the community (or IOHK).To Markus' rework: focus on security for feedback on Metadata standardization in the first version. Once there is a mechanism and two categories (Convenient and UnConvenient).
Focus on mechanism, security towards minimum amount of metadata to prevent issues.
Follow the JSON schema and explanation of each field. BIP44 or BIP32 has a template for similar extensions.
Future CIPs might want to add additional Metadata fields and should be structured in this way… it’ll provide a template for future discussions.
**Frederic** - Wrapping up on the meeting: Review ‘CIP6’ in 2 weeks.
‘Merge of CIP7’ once Legal ok.
Markus to talk to the community about security and minimal metadata...
**Sebastien** - CIP4 PR can likely be merged in/ a draft, should it merged? We brought it up in the past + it has been implemented in Yoroi already..
### Discussions
N/A - not enough time due to extended reviews.
CIP4 to be looked at in async channels and moved to next meeting.
### Close
**On Hold** Change Format of CIPs (in CIP1) (instead CIPx.md) - awaiting Frontend fix to auto-gen site
**TODO** Merge Curve proposal / ‘CIP7’ once legal oks.
---
## Extra
### Current CIPs in the CIP repository and their status
|# |Title | Status |
| ----------------- |:----------------|:-------------------- |
| 1 | [CIP Process](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0001) | Active |
| 2 | [Coin Selection Algorithms for Cardano](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0002) | Draft |
| 5 | [Common Bech32 Prefixes](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0005) | Draft |
:bulb: - For more details about Statuses, refer to [CIP1](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0001).
### CIP creation process as a Sequence Diagram
_"Alice has a Cardano idea she'd like to build more formally":_
### Understanding CIPs further
[](https://www.youtube.com/watch?v=q7U10EfqXJw)
[](https://www.youtube.com/watch?v=dnw7k7VKVyo)
================================================
FILE: BiweeklyMeetings/2020-10-06.md
================================================
**Table of Contents:**
- [Summary](#summary)
- [Editors Meeting Flow](#editors-meeting-flow)
- [October 06 2020 notes](#october-06-2020-notes)
* [Triage](#triage)
* [Last Check](#last-check)
+ [Extended Metadata](#Extended-Metadata)
+ [Curve Pledge Benefit](#Curve-Pledge-Benefit)
* [Review](#review)
+ [Wallet Checksums](#Wallet-Checksums)
+ [Message Signing](#Message-Signing)
* [Discussions](#discussions)
* [Close](#close)
- [Extra](#extra)
* [Current CIPs in the CIP repository and their status](#current-cips-in-the-cip-repository-and-their-status)
* [CIP creation process as a Sequence Diagram](#cip-creation-process-as-a-sequence-diagram)
* [Understanding CIPs further](#understanding-cips-further)
## Summary
Rough writeup of 10/6/20 Editors meeting notes taken during that day's CIP meeting, to increase transparency and dialogue with the community regarding proposed changes, implementations and considerations.
<sub>_Notes might contain errors or miss pieces - call out issues as needed_
</sub>
## Editors Meeting Flow
- [x] **Triage/Review**: Some CIPs might fall out of grace or not get updated, a CIP that hasn’t seen activity for 3 months should be checked on, and appropriate action taken. Ex: did any of the recent changes obsolete current CIPs? Consider ‘Active’ -> ‘Obsolete’ transitions..
- [x] **Last Check**: Review of the PRIOR meetings Decisions - if no objection, apply change (effectively a two week lag from decision to action, as a grace period)
- [x] **New CIPs Review**: CIPs up for review should be looked over collectively, with discussion where needed. (on top of the asynchronous reviews)
PR -> ‘Draft’: Needs format + approval.
‘Draft’ -> ‘Proposed’: Needs a PLAN towards Active + implementation.
‘Proposed’ -> ‘Active’: Objective criteria as laid out observed, and consensus agreeing.
- [x] **Current Discussions**: What the current CIPs discussions are on social media / forums / Discord.
- [x] **Close**: Recap of actions taken and decisions. List the CIPs that are due for review. Distribution of the minutes via mailing list.
## October 06 2020 notes
**Attending**: (Duncan, Frederic, Matthias, Sebastien) + Jeremy (CF) + Shawn (PR Author) + Nick (Community)
### Triage
N/A
### Last Check
#### Extended Metadata
([PR](https://github.com/cardano-foundation/CIPs/pull/15) - potential CIP6)
**Frederic** - “Extended Metadata” has been awaiting the result of conversations with major stakepool operators led by Markus, while Mike wanted to incorporate suggestions from Shawn. No activity since last meeting on the PR. Recommendation is to merge as a draft as discussed last meeting to start/enable the discussion.
**Sebastien** - Let’s wait another two weeks for the changes/comments that were expected in the PR to proceed.
#### Curve Pledge Benefit
([PR](https://github.com/cardano-foundation/CIPs/pull/12) - potential CIP7)
**Sebastien** - Still not sure if the proposal' incentives are fully sound but that’s for analysts to discuss.
**Matthias/Shawn** - Last CIP Editors meeting we agreed to merge it as a draft, pending some legal clarifications.
**Sebastien** - Can be merged as a draft. As formatting goes, ok to merge to advance the conversation.
**Frederic** - Still no word from legal, but Shawn agreed to remove copyright as Draft and amend the PR while unclear, ok to move as draft as-is and modify.
### Review
#### Wallet Checksums
([PR](https://github.com/cardano-foundation/CIPs/pull/4) - potential CIP4)
**Sebastien** - Yoroi extension and Yoroi wallet have already implemented a Wallet Checksum. Maps public keys to a picture and text block: People have often entered the wrong recovery phase numerous times, so the checksum means we receive less complaints (for user errors). This is ready to merge as draft I think.
#### Message Signing
([PR](https://github.com/cardano-foundation/CIPs/pull/27) - potential CIP8)
**Sebastien** - When you send a transaction you functionally prove you own the tokens via signing. You should therefore be able to prove any statement, not limited to tokens.
This is a specification of how to bundle together data (a message) and proof (signature) for a transaction. Agreed format for Yoroi and Daedalus, useful for off chain components.
The proposed format for how to structure the message is based on COSE, restricting/simplifying a bit the functionalities so it’s easier to use: COSE is a bit too complex for wallets to have a full implementation? The objective is to only support the algorithms that we are interested in using with Cardano. Here, you can submit headers as part of the message. In this specification many of the headers have been excluded.
Need to check if this approach can be used for Daedalus wallet.
**Duncan** - May have internal IOHK auditors to review, 2-3 weeks needed for review.
### Discussions
**Shawn** - What is the process for items to be put on the CIP Editors meeting agenda?
**Duncan** - Any relevant items, depending on capacity - easiest way is reach out to the Editors or flag it in Github.
(Discussion re: Pool ranking .. needs to be improved)
### Close
**On Hold** Change Format of CIPs (in CIP1) (instead CIPx.md)
“Curve proposal” (‘CIP7’) to be merged as ‘Draft’, legal tweaks to follow.
“Extended Metadata” (‘CIP6’) flagged for comments and updates next two week.
“Wallet Checksum” (‘CIP4’) to be merged as ‘Draft’ in 2 weeks.
---
## Extra
### Current CIPs in the CIP repository and their status
|# |Title | Status |
| ----------------- |:----------------|:-------------------- |
| 1 | [CIP Process](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0001) | Active |
| 2 | [Coin Selection Algorithms for Cardano](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0002) | Draft |
| 5 | [Common Bech32 Prefixes](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0005) | Draft |
| 7 | [Curve Pledge Benefit](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0007) | Draft |
:bulb: - For more details about Statuses, refer to [CIP1](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0001).
### CIP creation process as a Sequence Diagram
_"Alice has a Cardano idea she'd like to build more formally":_
### Understanding CIPs further
[](https://www.youtube.com/watch?v=q7U10EfqXJw)
[](https://www.youtube.com/watch?v=dnw7k7VKVyo)
================================================
FILE: BiweeklyMeetings/2020-10-20.md
================================================
**Table of Contents:**
- [Summary](#summary)
- [Editors Meeting Flow](#editors-meeting-flow)
- [October 20 2020 notes](#october-20-2020-notes)
* [Triage](#triage)
* [Last Check](#last-check)
+ [Extended Metadata](#Extended-Metadata)
+ [Wallet Checksums](#Wallet-Checksums)
* [Review](#review)
+ [Message Signing](#Message-Signing)
* [Discussions](#discussions)
* [Close](#close)
- [Extra](#extra)
* [Current CIPs in the CIP repository and their status](#current-cips-in-the-cip-repository-and-their-status)
* [CIP creation process as a Sequence Diagram](#cip-creation-process-as-a-sequence-diagram)
* [Understanding CIPs further](#understanding-cips-further)
## Summary
Rough writeup of 10/20/20 Editors meeting notes taken during that day's CIP meeting, to increase transparency and dialogue with the community regarding proposed changes, implementations and considerations.
<sub>_Notes might contain errors or miss pieces - call out issues as needed_
</sub>
## Editors Meeting Flow
- [x] **Triage/Review**: Some CIPs might fall out of grace or not get updated, a CIP that hasn’t seen activity for 3 months should be checked on, and appropriate action taken. Ex: did any of the recent changes obsolete current CIPs? Consider ‘Active’ -> ‘Obsolete’ transitions..
- [x] **Last Check**: Review of the PRIOR meetings Decisions - if no objection, apply change (effectively a two week lag from decision to action, as a grace period)
- [x] **New CIPs Review**: CIPs up for review should be looked over collectively, with discussion where needed. (on top of the asynchronous reviews)
PR -> ‘Draft’: Needs format + approval.
‘Draft’ -> ‘Proposed’: Needs a PLAN towards Active + implementation.
‘Proposed’ -> ‘Active’: Objective criteria as laid out observed, and consensus agreeing.
- [x] **Current Discussions**: What the current CIPs discussions are on social media / forums / Discord.
- [x] **Close**: Recap of actions taken and decisions. List the CIPs that are due for review. Distribution of the minutes via mailing list.
## October 20 2020 notes
**Attending**: (Duncan, Frederic, Matthias, Sebastien) + Ben (IO)
### Triage
N/A
### Last Check
#### Extended Metadata
([PR](https://github.com/cardano-foundation/CIPs/pull/15) - potential CIP6)
**Frederic** “Extended Metadata” has there been updates? Appears this is still on hold - let's wait another two weeks, authors were absent and outreach for info needed.
**Duncan** We should open it up to more people: maybe someone else might want to take it over?Let's not push it if there isn't interest.
**Sebastien** We're waiting for info on explorers.
**Duncan** As long as the authors are still engaged, that's fine.
**Sebastien** ADApools is the one who setup an extended metadata format (the format the CIP is based on): we wanted their feedback on this proposal.
**Frederic** Will Follow on. Ping them directly or invite them + authors.
=> **On Hold**
#### Wallet Checksum
([PR](https://github.com/cardano-foundation/CIPs/pull/4) - potential CIP4)
**Frederic** all good to go - (no objections).
### Review
#### Message Signing
([PR](https://github.com/cardano-foundation/CIPs/pull/27) - potential CIP8)
**Duncan** Good feedback from IOG.
**Sebastien** Voltaire voting is coming up, I would like for it to be merged now (as it was discussed on the last call).
**Frederic** We're working in the context of "CIPs are a set of tools that implementers can pick and choose as they want" and it seems IOG might consider CIP to be canon for the main protocol.. CH brought up CRCs ("Cardano Request for Comments" - open discussion towards Cardano standards) - we touched to those in the past and at the time we agreed on proceeding with CIPs being non-restrictive.
**Duncan** All things being equal, it's preferable to have one general guideline rather than three because of interoperability. Mild preference for a single standard for message signing. We lightly discussed merging this now last meeting, let's proceed.
=> **MERGING** now
### Discussions
**Duncan** Suggest we move CIP5 into "Proposed" state, and require details of the plan while it's in "Proposed" state?
**Frederic** "Proposed" must have defined metrics of acceptance/plan to Active.
**Frederic** Propose we keep every 10 meetings as small (agreement). Propose we try out Crowdcast for next meeting. Need a Pr to fix numbering issues and links.
**Duncan** We also need a better chart or table at top-level: a readme would be helpful...
**Frederic** the (CIP auto gen site) is being managed by IOG; slow to get issues fixed unfortunately
### Close
**On Hold** Change Format of CIPs (in CIP1) (instead CIPx.md)
**ON Hold** “Curve proposal” (‘CIP7’) still awaiting legal followup
**ON Hold** [“Extended Metadata”](https://github.com/cardano-foundation/CIPs/pull/15) (potential ‘CIP6’) re: comments and updates
=> Merge **NOW**: [“Wallet Checksum”](https://github.com/cardano-foundation/CIPs/pull/4) to be merged as ‘Draft’ (‘CIP4’)
=> Merge **NOW**: [“Message Signing”](https://github.com/cardano-foundation/CIPs/pull/27)to be merged as ‘Draft’ (‘CIP8’)
---
## Extra
### Current CIPs in the CIP repository and their status
|# |Title | Status |
| ----------------- |:----------------|:-------------------- |
| 1 | [CIP Process](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0001) | Active |
| 2 | [Coin Selection Algorithms for Cardano](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0002) | Draft |
| 4 | [Wallet Checksum](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0004) | Draft |
| 5 | [Common Bech32 Prefixes](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0005) | Draft |
| 7 | [Curve Pledge Benefit](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0007) | Draft |
| 8 | [Message Signing](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0008) | Draft |
:bulb: - For more details about Statuses, refer to [CIP1](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0001).
### CIP creation process as a Sequence Diagram
_"Alice has a Cardano idea she'd like to build more formally":_
### Understanding CIPs further
[](https://www.youtube.com/watch?v=q7U10EfqXJw)
[](https://www.youtube.com/watch?v=dnw7k7VKVyo)
================================================
FILE: BiweeklyMeetings/2020-11-03.md
================================================
**Table of Contents:**
- [Summary](#summary)
- [Editors Meeting Flow](#editors-meeting-flow)
- [November 3 2020 notes](#november-3-2020-notes)
* [Triage](#triage)
* [Last Check](#last-check)
* [Review](#review)
+ [Extended Metadata](#Extended-Metadata)
+ [Wallet key generation](#Wallet-key-generation)
+ [HD Wallet for Cardano](#HD-Wallet-for-Cardano)
+ [Transaction Metadata Registry](#Transaction-Metadata-Registry)
+ [Cardano URI Scheme](#Cardano-URI-Scheme)
+ [ Treasury Fraction on actual distributed rewards](#Treasury-Fraction-on-actual-distributed-rewards)
* [Discussions](#discussions)
* [Close](#close)
- [Extra](#extra)
* [Current CIPs in the CIP repository and their status](#current-cips-in-the-cip-repository-and-their-status)
* [CIP creation process as a Sequence Diagram](#cip-creation-process-as-a-sequence-diagram)
* [Understanding CIPs further](#understanding-cips-further)
## Summary
Rough writeup of 11/3/20 Editors meeting notes taken during that day's CIP meeting, to increase transparency and dialogue with the community regarding proposed changes, implementations and considerations.
<sub>_Notes might contain errors or miss pieces - call out issues as needed_
</sub>
## Editors Meeting Flow
- [x] **Triage/Review**: Some CIPs might fall out of grace or not get updated, a CIP that hasn’t seen activity for 3 months should be checked on, and appropriate action taken. Ex: did any of the recent changes obsolete current CIPs? Consider ‘Active’ -> ‘Obsolete’ transitions..
- [x] **Last Check**: Review of the PRIOR meetings Decisions - if no objection, apply change (effectively a two week lag from decision to action, as a grace period)
- [x] **New CIPs Review**: CIPs up for review should be looked over collectively, with discussion where needed. (on top of the asynchronous reviews)
PR -> ‘Draft’: Needs format + approval.
‘Draft’ -> ‘Proposed’: Needs a PLAN towards Active + implementation.
‘Proposed’ -> ‘Active’: Objective criteria as laid out observed, and consensus agreeing.
- [x] **Current Discussions**: What the current CIPs discussions are on social media / forums / Discord.
- [x] **Close**: Recap of actions taken and decisions. List the CIPs that are due for review. Distribution of the minutes via mailing list.
## November 3 2020 notes
**Attending**: (Duncan, Frederic, Matthias, Sebastien) + Ben (IO) + Markus (community)
### Triage
N/A
### Last Check
N/A
### Review
#### Extended Metadata
([PR](https://github.com/cardano-foundation/CIPs/pull/15) - potential CIP6)
**F** - Last we looked at this CIP, the ask was for comments/feedback from major pools. Cardanians replied two weeks ago.
**S** - Some parts we're still unsure re: security model - the RSS feel might not have been fully thought through. I think issues might have been addressed since.
**M** - sorry was busy past month. I have some tech Q: what do we need to do with what is already existing from the CLI to generate an additional key? That key could be generated so the extended metadata can be verified, so Yoroi/Daedalus can accept the metadata.
**D** - Are you talking about a first level metadata contains a keyhash and a URL (to the secondary metadata level)?
**M** - Yes, to be more flexible for the 2nd level: no codekey to update the (2nd level) extended metadata but with some hash or verification mechanism. So that means another key should be generated (am against too many hashes onchain).
**D** - We extend the first/primary level metadata with two extra fields: One is the PubKeyhash (that will be used to sign the 2nd level metadata) and the URL of where to find the 2nd level MD. The 2nd level MD is found at URL, and there is some signature that accompanies it (signed/verifiable against 1st lvl keyhash). If that is the case, you can change the 2nd level metadata without re-registering the pool. And also update the 1st level metadata without having to change the key for the 2nd level metadata.
**M** - Right now we have a hash onchain of the prime metadata. I want to summarize fields so the proposal can start with "the minimum metadata". What I mean to summarize is that this CIP should contain a proposal for what "future extended metadata should look like" and I need your feedback on key types to use etc.
**D** - Ordinary ed25519 key is the simplest thing to do.
**M** - Need more time from Mike also - and need some feedback from other groups to weigh in - there wasn't much feedback unfortunately. This is a fairly easy and non-technical CIP.
**D** - Focus on the details of the mechanism, but also what the exact format of the witness/signature.
**M** - I'll try it out and seek your feedback in the PR through comments.
**Matthias** - For signature, go with simplest: if that's embedded, or on the side.. We don't want to complicate things.
**M** - From operative pt of view, if SPO wants to integrate, it should be straightforward.
**D** - Two files ok?
**M** - yes - because when ext-metadata file is updated then would need to do other file (signature).
**D** - The CLI would validate the json and generate the signature for you... But still two files you host.
**M** - Yes, some external tool / CMS whatever SPO has, can generate the new extended metadata file and you send it to the CLI, which creates the signature of the new extended metadata file. Probably need two URL fields in 1st level. Mike's feedback originally was that he didn't want to update base URL in .json.
**D** - ok maybe two URL.
=> On Hold, Markus to add comments to which Duncan will follow up in the PR regarding scheme.
#### Wallet key generation
([PR](https://github.com/cardano-foundation/CIPs/pull/3) - potential CIP3)
**S** - Added test vectors and took comments on the PR. A Fairly small CIP, bulk of is the Test Vectors. I got them from Matthias and some independantly tested on the Yoroi codebase. No problems with Keygen.
**M** - I intended to review and approve last week, thanks for the TVs - no issues. This is an excerpt of a diff doc we reviewed as a team - used to be part of Adrestia userguide/docs. The masterkey gen was extracted from the docs into this CIP..
**S** - This comes from the Adrestia docs and Trezor documentation and I added extra about the passphrase feature... Also added the passphraze feature for Ledger which wasn't in the docs. When creating via Trezor and selecting the 24 word option it uses a diff alg that nobody knows of (Matthias: "yet").
**D** - Fine if you both approve this.
**M** - All the new wallets are using the Icarus version, the more prevalent standard - I propose we add that to this CIP that for new applications we recommend this version. (agreement).
=> Merge in two weeks
#### HD Wallet for Cardano
([PR](https://github.com/cardano-foundation/CIPs/pull/27) - potential CIP1852)
**S** - This one has a lot of history behind it - we had to represent that new staking key and needed it to be deterministic so Yoroi and Daedalus had to have the same staking key. The easiest way is to just derive it from the Master key so we added a new chain derivation. We added a chain derivation we added a 2-chain & called it "Chimeric account" which came from jormungandr (due to originally keys were the same). We could rename it for "staking key chain"...
**M** - We just started calling it "Roles". We also use it for the multisig key. I would push we publish this CIP very soon.
**D** - I think that's most sensible terminology..
**M** - Catalyst team decided to have complely different HD tree, so completely diff mnemonic - the rationale is that the voting wallet should be completely separate and independant from the voting wallet...
**S** - Bad idea likely but we can discuss some other time. I'll rewrite the CIP. Do you want every new role we add to be a separate CIP?
**M** - I would prefer one explaining the general naming, and then individual CIPs for new roles we add. But open to doing PR to that one CIP also for reference... Can do the same as we for Metadata Registry.
**S** - I'll split this CIP in two parts then (a CIP for allocating numbers and a separate CIP for the specific role itself)
=> ON hold, Sebastien to split into two
#### Transaction Metadata Registry
([PR](https://github.com/cardano-foundation/CIPs/pull/34) - potential CIP10)
**S** - Every Tx in Cardano contains Tx Metadata, stored as a map of unsigned numbers to CBOR. We can use this map as a namespace, but to have it be as an effective namespace we need some sort of registry where people can document what number they are using for what purposes, and/or define possibly reserved/specific ranges.
**S** - The SPOCRA ppl already started metadata and have 200-300 Tx on mainnet. They will probably be the first to allocate numbers...
**D** - Let's setup a private range now. Start with '0'. We should be explicit... ex 0-255: 'reserved'. We should have a small and large reserve range. Proposing we go with [0-15] - (agreement). Also [2^16 to 2^17 - 1] for private use, so that guaranteed not to clash with interoperable ones.
=> Merge **NOW** (as other CIPs will depend on this / need the draft).
#### Cardano URI Scheme
([PR](https://github.com/cardano-foundation/CIPs/pull/30) - potential CIP)
**S** - We will need to change and merge two CIPs together. Moving on.
#### Treasury Fraction on actual distributed rewards
([PR](https://github.com/cardano-foundation/CIPs/pull/35) - potential CIP)
**S** - This was on the agenda so we can get Duncan's take on who should be involved.
**D** - Lars Brunje. He'll direct through the right teams review and provide feedback.
### Discussions
**F** - Crowdcast issues. Will follow-up and attempt to resolve for next meeting.
### Close
**ON Hold** “Curve proposal” (‘CIP7’) still awaiting legal followup
**ON Hold** [“Extended Metadata”](https://github.com/cardano-foundation/CIPs/pull/15) (potential ‘CIP6’) - extend conversation in PR.
**ON Hold** [“HD Wallet for Cardano”](https://github.com/cardano-foundation/CIPs/pull/27) (potential ‘CIP1852’) - to be split into two PRs by Sebastien
**ON Hold** [“Treasury”](https://github.com/cardano-foundation/CIPs/pull/35) (potential CIP) - Requesting feedback and review from scientists
=> Merge in two weeks: [“Wallet key generation”](https://github.com/cardano-foundation/CIPs/pull/3) to be merged as ‘Draft’ (‘CIP3’)
=> Merge **NOW**: [“Metadata Registry”](https://github.com/cardano-foundation/CIPs/pull/34)to be merged as ‘Draft’ (‘CIP10’)
---
## Extra
### Current CIPs in the CIP repository and their status
|# |Title | Status |
| ----------------- |:----------------|:-------------------- |
| 1 | [CIP Process](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0001) | Active |
| 2 | [Coin Selection Algorithms for Cardano](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0002) | Draft |
| 4 | [Wallet Checksum](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0004) | Draft |
| 5 | [Common Bech32 Prefixes](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0005) | Draft |
| 7 | [Curve Pledge Benefit](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0007) | Draft |
| 8 | [Message Signing](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0008) | Draft |
| 10 | [Transaction Metadata Label Registry](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0010) | Draft |
:bulb: - For more details about Statuses, refer to [CIP1](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0001).
### CIP creation process as a Sequence Diagram
_"Alice has a Cardano idea she'd like to build more formally":_
### Understanding CIPs further
[](https://www.youtube.com/watch?v=q7U10EfqXJw)
[](https://www.youtube.com/watch?v=dnw7k7VKVyo)
================================================
FILE: BiweeklyMeetings/2020-11-17.md
================================================
**Table of Contents:**
- [Summary](#summary)
- [Editors Meeting Flow](#editors-meeting-flow)
- [November 17 2020 notes](#november-17-2020-notes)
* [Triage](#triage)
* [Last Check](#last-check)
+ [Wallet key generation](#Wallet-key-generation)
* [Review](#review)
+ [Treasury Fraction on actual distributed rewards](#Treasury-Fraction-on-actual-distributed-rewards)
+ [Extended Metadata](#Extended-Metadata)
+ [Staking Key Chain for HD Wallets](#Staking-Key-Chain-for-HD-Wallets)
+ [HD Wallet for Cardano](#HD-Wallet-for-Cardano)
+ [Cardano URI Scheme](#Cardano-URI-Scheme)
* [Discussions](#discussions)
* [Close](#close)
- [Extra](#extra)
* [Current CIPs in the CIP repository and their status](#current-cips-in-the-cip-repository-and-their-status)
* [CIP creation process as a Sequence Diagram](#cip-creation-process-as-a-sequence-diagram)
* [Understanding CIPs further](#understanding-cips-further)
## Summary
Rough writeup of 11/17/20 Editors meeting notes taken during that day's CIP meeting, to increase transparency and dialogue with the community regarding proposed changes, implementations and considerations.
<sub>_Notes might contain errors or miss pieces - call out issues as needed_
</sub>
## Editors Meeting Flow
- [x] **Triage/Review**: Some CIPs might fall out of grace or not get updated, a CIP that hasn’t seen activity for 3 months should be checked on, and appropriate action taken. Ex: did any of the recent changes obsolete current CIPs? Consider ‘Active’ -> ‘Obsolete’ transitions..
- [x] **Last Check**: Review of the PRIOR meetings Decisions - if no objection, apply change (effectively a two week lag from decision to action, as a grace period)
- [x] **New CIPs Review**: CIPs up for review should be looked over collectively, with discussion where needed. (on top of the asynchronous reviews)
PR -> ‘Draft’: Needs format + approval.
‘Draft’ -> ‘Proposed’: Needs a PLAN towards Active + implementation.
‘Proposed’ -> ‘Active’: Objective criteria as laid out observed, and consensus agreeing.
- [x] **Current Discussions**: What the current CIPs discussions are on social media / forums / Discord.
- [x] **Close**: Recap of actions taken and decisions. List the CIPs that are due for review. Distribution of the minutes via mailing list.
## November 17 2020 notes
**Attending**: (Duncan, Frederic, Matthias, Sebastien) + Colin, Lars (IO) + Marek, Federico (community)
### Triage
N/A
### Last Check
#### Wallet key generation
([PR](https://github.com/cardano-foundation/CIPs/pull/3) - potential CIP3)
**S** - minor column changes being added. Merge Once reviewed by Matthias.
=> Merge as soon as reviewed
### Review
#### Treasury Fraction on actual distributed rewards
([PR](https://github.com/cardano-foundation/CIPs/pull/35) - potential CIP)
**Lars** - A portion of the rewards pool is UNSPENT every epoch - very early, it was planned to go to the treasury (old scheme) - which reduced to about 50% going to the treasury, so now what is left goes to the reserves, which is good because Reserves last longer with Inflation. The CIP Author however highlighted that this however, means somehow a double taxation setup, where the same coins get taxed over and over.
The suggestion is to change "when" the 20% go to the treasury, the suggestion is that it not be taken from the pot but rather from the rewards.This was mentionned to Aggelos also who agreed it was a good idea. Might have to adjust the rate to account for the changes.
**Federico** - exactly - We're proposing that we apply the Tau param on the real distributed reward, not the reward pot itself. Our proposal is based on what we need to change in the specs to achieve that result - so instead of calculating the fractionning at the beginning of the process, we move Tau application on the distributed rewards. Shouldn't be too technically challenging to implement.
**Sebastien** - Do you specify a percentage in here?
**F** - No, this is simply a proposition so the conversation can take place. Now, we don't see the big difference we were seeing before. Ex: with the arrival of Binance the ammount of delegated ada went from from 50% to 65-66%. Still, we're experiencing real 30 - 35% Taxation rather than the 20% that is specified by Tau param.
**S** so next steps is to merge this PR then go to IOHK to look at percent
**Colin** Q in terms of actual calculation: Right now the epoch expansion is kinda scaled by the participation rate. The rewards are as if all the stakes was pledged and received pledge reward. If we just divided through the Epoch reward by 1+a0 parameter...
(Back and forth about Monetary expansion setup)
**F** - Tau levvy is applied on reward pot before calculating rewards (+Frederic +Lars)
(Looking at [ledger specs](https://hydra.iohk.io/job/Cardano/cardano-ledger-specs/shelleyLedgerSpec/latest/download-by-type/doc-pdf/ledger-spec))
**L** - Page 62. Middle of the page. Jarod ideally the good person to ask (or Philipp).
**D** - Before the shelley release, we changed where unpaid ada went - to Reserves. It looks like there is a sentence off in there: "The difference between the maximal amount and the actual amound received is added to the amount moved to the treasury" it should say go to reserve, not treasury.
**D** - Probably correct in the mathematics but not the prose.
**L** - It says october 2019 which seems old?
**D** - You're looking at the right version - Delta T1, is the ammount that goes to the treasury. The change to the reserves is Delta R1 and Delta R2. The formal spec is correct, the text is off, should be ammended.
**F** - The discussion is about the unclaimed rewards, for varied reasons. We want to minimize the multi-treasury taxation.
**S** - Two pts. double taxation. convo can happen offline. Changing Tau is not a HF event.
**D** - I agree taking the Treasury percentage at the end rather than the beginning is a reasonable thing, but would also need a HF. Let's get specific changes in the CIP itself and review then.
(=> To be followed up on structure-wise next meeting, pending added clarifications)
#### Extended Metadata
([PR](https://github.com/cardano-foundation/CIPs/pull/15) - potential CIP6)
**Frederic** - Some conversation happened in PR but missing answers/followup
**Matthias** - I don't think there is any edition problem. I would like to see this merged as a Draft and let the convo continue.
**F** - I'm with Matthias, would want to move this and let conversation continue as Draft.
**D** - It's distracting to have contingent conversations about content, easier to start with a detailed mechanism. Then we can add to it incrementally.
**S** - Pushing out to next meeting.
=> Follow-up next meeting.
#### Staking Key Chain for HD Wallets
([PR](https://github.com/cardano-foundation/CIPs/pull/37) - potential CIP)
**S** - This is one of the two CIPs I split 1852 in. This one specifies the key/derivation path.
**M** - Haven't reviewed. will do until next meeting.
=> Merge in two weeks pending Matthias review
#### HD Wallet for Cardano
([PR](https://github.com/cardano-foundation/CIPs/pull/33) - potential CIP1852)
**S** - The other CIP from 1852. This one is intent as the registry of the different chains used in Cardano. It uses 0/1 for BIP44. For example, If we were to add staking keys, then those would be added here, so we can know which index means what.
=> Merge in two weeks pending Matthias review
#### Cardano URI Scheme
([PR](https://github.com/cardano-foundation/CIPs/pull/30) - potential CIP)
**S** - Could be merged ... but nobody has had time to review yet.
=> Move to next meeting
### Discussions
**F** - We tried Crowdcast and reverted to GMeet. Want to push [Crowdcast](https://www.crowdcast.io/cips-biweekly) going forward (=> did sync post-meeting: all seem sorted out).
Had a Github history mixup due to force Push: reminder to be careful, now CIP10 inception only in history from a side reference. Yet want to consider force-pushing meeting notes rather than awaiting reviews, as they keep taking longer.
Conversation was setup with R. Moore's team to take over the [cips.cardano.org](cips.cardano.org) site for next week. Note that [PR #42](https://github.com/cardano-foundation/CIPs/pull/42) WILL break the site further, but it will functionally be better flowing due to minor tweaks.
### Close
**ON Hold** “Curve proposal” (‘CIP7’) still awaiting legal followup
**ON Hold** [“Extended Metadata”](https://github.com/cardano-foundation/CIPs/pull/15) (potential ‘CIP6’) - another two week hold potentially merging depending on week convo/Duncan.
**ON Hold** [“Treasury”](https://github.com/cardano-foundation/CIPs/pull/35) (potential CIP) - no plan to merge but will reconsider
=> Merge in two weeks: [“HD Wallet for Cardano”](https://github.com/cardano-foundation/CIPs/pull/33) (potential ‘CIP1852’)
=> Merge in two weeks: [“Staking Key Chain for HD Wallets”](https://github.com/cardano-foundation/CIPs/pull/37) (potential ‘CIP’)
=> Merge **NOW**: [“Wallet key generation”](https://github.com/cardano-foundation/CIPs/pull/3) to be merged as ‘Draft’ (‘CIP3’)
---
## Extra
### Current CIPs in the CIP repository and their status
|# |Title | Status |
| ----------------- |:----------------|:-------------------- |
| 1 | [CIP Process](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0001) | Active |
| 2 | [Coin Selection Algorithms for Cardano](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0002) | Draft |
| 3 | [Wallet key generation](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0003) | Draft |
| 4 | [Wallet Checksum](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0004) | Draft |
| 5 | [Common Bech32 Prefixes](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0005) | Draft |
| 7 | [Curve Pledge Benefit](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0007) | Draft |
| 8 | [Message Signing](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0008) | Draft |
| 10 | [Transaction Metadata Label Registry](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0010) | Draft |
:bulb: - For more details about Statuses, refer to [CIP1](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0001).
### CIP creation process as a Sequence Diagram
_"Alice has a Cardano idea she'd like to build more formally":_
### Understanding CIPs further
[](https://www.youtube.com/watch?v=q7U10EfqXJw)
[](https://www.youtube.com/watch?v=dnw7k7VKVyo)
================================================
FILE: BiweeklyMeetings/2020-12-08.md
================================================
**Table of Contents:**
- [Summary](#summary)
- [Editors Meeting Flow](#editors-meeting-flow)
- [December 8 2020 notes](#december-8-2020-notes)
* [Triage](#triage)
* [Last Check](#last-check)
+ [PR37 - Staking Key Chain for HD Wallets](#Staking-Key-Chain-for-HD-Wallets)
+ [PR33 - HD Wallets for Cardano](#HD-Wallets-for-Cardano)
* [Review](#review)
+ [PR30 - Cardano URI Scheme](#Cardano-URI-Scheme)
+ [PR45 - Cardano Protocol Parameters](#Cardano-Protocol-Parameters)
+ [PR44 - On-chain stake pool operator to delegates communication](#On-chain-stake-pool-operator-to-delegates-communication)
+ [PR15 - Extended Metadata](#Extended-Metadata)
* [Discussions](#discussions)
* [Close](#close)
- [Extra](#extra)
* [Current CIPs in the CIP repository and their status](#current-cips-in-the-cip-repository-and-their-status)
* [CIP creation process as a Sequence Diagram](#cip-creation-process-as-a-sequence-diagram)
* [Understanding CIPs further](#understanding-cips-further)
## Summary
Rough writeup of 12/08/20 Editors meeting notes taken during that day's CIP meeting, to increase transparency and dialogue with the community regarding proposed changes, implementations and considerations.
<sub>_Notes might contain errors or miss pieces - call out issues as needed_
</sub>
## Editors Meeting Flow
- [x] **Triage/Review**: Some CIPs might fall out of grace or not get updated, a CIP that hasn’t seen activity for 3 months should be checked on, and appropriate action taken. Ex: did any of the recent changes obsolete current CIPs? Consider ‘Active’ -> ‘Obsolete’ transitions..
- [x] **Last Check**: Review of the PRIOR meetings Decisions - if no objection, apply change (effectively a two week lag from decision to action, as a grace period)
- [x] **New CIPs Review**: CIPs up for review should be looked over collectively, with discussion where needed. (on top of the asynchronous reviews)
PR -> ‘Draft’: Needs format + approval.
‘Draft’ -> ‘Proposed’: Needs a PLAN towards Active + implementation.
‘Proposed’ -> ‘Active’: Objective criteria as laid out observed, and consensus agreeing.
- [x] **Current Discussions**: What the current CIPs discussions are on social media / forums / Discord.
- [x] **Close**: Recap of actions taken and decisions. List the CIPs that are due for review. Distribution of the minutes via mailing list.
## December 8 2020 notes
**Attending Editors**: (Duncan, Frederic, Matthias, Sebastien).
### Triage
N/A
### Last Check
#### Staking Key Chain for HD Wallets
([PR37](https://github.com/cardano-foundation/CIPs/pull/37) - potential CIP-0011)
**Matthias** - Good to merge and proceed.
=> **MERGING** now
#### HD Wallets for Cardano
([PR33](https://github.com/cardano-foundation/CIPs/pull/33) - potential CIP-1852)
**M** - This one actually should be merged first since PR37 references it. It will function as a Hub for all the extensions going forward, such as staking keys, multi-sig wallet keys (using same purpose but different chain)..
=> **MERGING** now
### Review
#### Cardano URI Scheme
([PR30](https://github.com/cardano-foundation/CIPs/pull/30) - potential CIP)
**S** - The issue is there is another multipool wants to merge into this one and have not heard from them, so not sure if we want to merge this and then merge the multi-pool in after - ok with either option. PR25. They were intent on merging into this CIP. Could deal with it later.
**F** - Could we merge their PR rather than this?
**S** - This one is ready to go, would be fine as-is.
**M** - Going through it... There is no existing implementation of that is there..?
**S** - Yes there is, Yoroi/Extension - the code is opensource
**M** - Format is good, Grammar fine, we could add it in. Addresses are said to be base58 - we want to add Bech32 in there.
=> Merge in two weeks
#### Cardano Protocol Parameters
([PR45](https://github.com/cardano-foundation/CIPs/pull/45) - potential CIP)
**F** - Pushed by IOHK's Kevin Hammond, this is looking at the intial Protocol parameters as pushed in the genesis file.
**M** - For Mainnet.
**S** - Makes sense - concerned the actual OnChain version drifts from this CIP but could deal with that.
**M** - Would like to structure this by Era - which would be easier. It could be something that might be mentionned in the CIP expaining that Parameters can drift.
**S** - If we can auto-generate this, that would be ideal.
**M** - It doesn't exist yet as a service if we want to automate it. I like the idea of the CIP however as explanining things.
**S** - What next?
**M** - Would require changes: disclaimer, link to genesis file...
**F** - Doesn't the genesis file reflect the actual parameters as-is?
**M** - Only at genesis - the parameters themselves can be updated OnChain through a special kind of transaction. To figure out what the current actual parameters are, you basically have to go through the rest of the chain and cherry-pick the blocks that have those special transactions, iterate from genesis and apply changes.
**F** - Adding this in this PR sounds useful.
**M** - Could be, also to identify out of those parameters which are updateable, and which are not: for example, the epoch length and slot length are not updateable, but the transaction max size it.
**S** - I assumed this CIP was if people would want to propose parameters changes - if we want to make this we want to change.
**Marek** - for this particular CIP I see this as for the *intial* parameters, not sure if this deals with *changing* the parameters.
**Duncan** - Romain wanted this a a CIP to get feedback on the initial parameters, because they can be changed. While it's still centralized, changes could be made to IOHK through this CIP... I think we should decide amongst ourselves what the best method might be: this as a living CIP or rather people proposing follow-on CIPs. Whichever fits the CIP process better. While we still have centralized governance, give some decentralized input. We're transitioning towards decentralized control. While the OnChain gov is centralized, this mechanism can provide input for that.
**S** - Prefer this CIP be modified for each changes, and then when a new genesis block is added we flag it here.
**Markus** - I like to have this CIP for intial params. This should have happened before. If we do it for future changes, then it would be better as a *new* CIP. I agree with Matthias - should be made clear which can be tweaked and which require a HF for change.
**Matthias** - Do you mean one CIP per Hardfork?
**Markus** - At least for every HardFork, maybe for protocol updates.
**D** - This only contains updateable characters.
**Matthias** - We should add the non-updateable parameters then (of the genesis file)
**D** - Good idea.
**F** - I think it'd be easier if kept in one CIP. I think both can work, Markus' option should be explored.
**D** - Another CIP would enable a fleshed out rationale.
**Markus** - If we do through PRs for soft-changes and new CIP for Hardforks, then we should rename this one.
**D** - This CIP should highlight how future changes would be done.
**F** - This one as Standards might be better as Informational to support the state of things.
**D** - Advantages are that for "at least this moment" they are proposals, and not enactments. Always the point of CIPs, providing a filter for things that are sensible, so some things might get proposed but other competing ones might get implemented. Let's put in this CIP a Proposed way about proposing protocol changes.
**D** - Let's propose the changes rather than burden Kevin? Change to Informational & others.
**Marek** - will work on it.
=> Review in two weeks
#### On-chain stake pool operation to delegates communication
([PR44](https://github.com/cardano-foundation/CIPs/pull/44) - potential CIP)
**Marek** - When looking at the communication between SPOs and Delegates from the perspective of the chain, we have 3 main channels, such as Offchain, Metadata-based (ex:CIP6), and for cases where you want to be OnChain. Benefits and disadvantages, but this is verifyable, auditable. I think the format is not as important as to how we will send the metadata. Two ways to send, distinguished by label. I wanted to open it up for discussion, still working on change requested.
**D** - Why do this rather than a RSS feed... Why want it auditable?
**M** - We're seeing Phishing on behalf of SPOs for example, the usecase here is for direct communication. So SPOs can ask delegates gradually or with certain ammount of stake. This enables directed communication. Adapools.org does the communication offchain. Cost is a feature, for example wallets could have granular control... Another advantage is the history here.
Not sure how much this will be used in the future but wanted to cover that space.
**D** - Seems focused on folks that work on the Wallet frontends.
**Matthias** - I don't think Darko would have any problem with having multiple CIPs for this, the implementation would fall on my team.
**S** - I think this is nice to have. I'm not a fan of markdown as too much of a risk sent to wallet. I prefer simpler format.
**Marek** - I was reluctant to send link to delegators even.
**Matthias** - For security purpose shouldn't add links. If your delegators knows your pool, they should know where to get your official notfications. The msg pushed by the pool to delegator should be able to say "I am your pool, I have this message, please go see on my official channel for more".
**Marek** - Because this has a cost associated with it, it might be interested for wallet users also - it disincentivizes the spam from the pool too.
**D** - Reasonable proposal.
**S** - let's remove the link part, and merge.
**Marek** - will do changes now, can do now.
=> Merge in two weeks
#### Extended Metadata
([PR15](https://github.com/cardano-foundation/CIPs/pull/44) - potential CIP-0006)
**Markus** - I replied to Duncan's comment in the PR. I reworked the entire proposal and it now includes the basic principles of how to generate a signable verifyable extended metadata. I tried to do with the existing CLI but with ran into error with the existing TxSign. Using a standard json scheme, not existing. The Txfile requires an initial key name (?) type.. We either need to have the cardano type extended or design the scheme for the extended metadata. The second step is the calc. of the hash, tried with shelley stake pool metadata and raw json, error about filesize (>512b)
**D** - That can be changed.
**Markus** - Also, outside, I got asked why use this mechanism instead of the Tx metadata to push verification keys and signed Tx OnChain. It's feasible but would require fully sync'd chain and a dbsync instance. If one hasn't, then it's a trust matter.
**F** - Sounds like a separate CIP - here the title could be clarified. Want this to be merged.
**Markus** - Let's keep in mind: we need CLI support for this to be actually implemented.
**F** - Right - Inclusion to repo does not imply it will be imlemented, hopefully support in CLI comes.
**Markus** - Re: Focus on mechanism rather than content, if we don't include the most important fields for metadata, then pools will be using the existing, and not care. We should offer at least the most important ones.
**D** - It needs both to be implemented and be used. Let's not pack too much into a CIP, this can be extended once it's implemented.
=> Merge in two weeks (?)
### Discussions
- out of time -
### Close
**ON Hold** “Curve proposal” (‘CIP7’) still awaiting legal followup
**ON Hold** [PR35 - “Treasury”](https://github.com/cardano-foundation/CIPs/pull/35) (potential CIP) - no plan to merge but will reconsider
=> Last Check - Merge in two weeks pending approvals: [PR15 - “Extended Metadata”](https://github.com/cardano-foundation/CIPs/pull/15) (tentative ‘CIP-0006’)
=> Last Check - Merge in two weeks pending approvals: [PR44 - "On-chain stake pool operator to delegates communication"](https://github.com/cardano-foundation/CIPs/pull/44) (potential 'CIP-0012')
=> Last Check - Merge in two weeks pending approvals: [PR30 - Cardano URI Scheme](https://github.com/cardano-foundation/CIPs/pull/30) (tentative 'CIP-00xx')
=> Merge **NOW**: [PR33 - HD Wallet for Cardano”](https://github.com/cardano-foundation/CIPs/pull/33) (‘CIP-1852’)
=> Merge **NOW**: [PR37 - “Staking Key Chain for HD Wallets”](https://github.com/cardano-foundation/CIPs/pull/37) (‘CIP-0011’)
---
## Extra
### Current CIPs in the CIP repository and their status
|# |Title | Status |
| ----------------- |:----------------|:-------------------- |
| 1 | [CIP Process](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0001) | Active |
| 2 | [Coin Selection Algorithms for Cardano](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0002) | Draft |
| 3 | [Wallet key generation](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0003) | Draft |
| 4 | [Wallet Checksum](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0004) | Draft |
| 5 | [Common Bech32 Prefixes](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0005) | Draft |
| 7 | [Curve Pledge Benefit](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0007) | Draft |
| 8 | [Message Signing](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0008) | Draft |
| 10 | [Transaction Metadata Label Registry](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0010) | Draft |
:bulb: - For more details about Statuses, refer to [CIP1](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0001).
### CIP creation process as a Sequence Diagram
_"Alice has a Cardano idea she'd like to build more formally":_
### Understanding CIPs further
[](https://www.youtube.com/watch?v=q7U10EfqXJw)
[](https://www.youtube.com/watch?v=dnw7k7VKVyo)
================================================
FILE: BiweeklyMeetings/2021-01-12.md
================================================
**Table of Contents:**
- [Summary](#summary)
- [Editors Meeting Flow](#editors-meeting-flow)
- [January 12 2021 notes](#january-12-2021-notes)
* [Triage](#triage)
* [Last Check](#last-check)
+ [PR15 - Extended Metadata](#Extended-Metadata)
+ [PR44 - On-chain stake pool operator to delegates communication](#On-chain-stake-pool-operator-to-delegates-communication)
+ [PR30 - Cardano URI Scheme](#Cardano-URI-Scheme)
* [Review](#review)
+ [PR46 - Shelley Protocol Parameters](#Shelley-Protocol-Parameters)
+ [PR56 - HD Stake pool cold keys](#HD-Stake-pool-cold-keys)
+ [PR58 - Catalyst Registration transaction metadata format](#Catalyst-Registration-transaction-metadata-format)
* [Discussions](#discussions)
* [Close](#close)
- [Extra](#extra)
* [Current CIPs in the CIP repository and their status](#current-cips-in-the-cip-repository-and-their-status)
* [CIP creation process as a Sequence Diagram](#cip-creation-process-as-a-sequence-diagram)
* [Understanding CIPs further](#understanding-cips-further)
## Summary
Rough writeup of 01/12/21 Editors meeting notes taken during that day's CIP meeting, to increase transparency and dialogue with the community regarding proposed changes, implementations and considerations.
<sub>_Notes might contain errors or miss pieces - call out issues as needed_
</sub>
Editors meetings are [public](https://www.crowdcast.io/cips-biweekly), [recorded](https://www.crowdcast.io/cips-biweekly) and [summarized](https://github.com/cardano-foundation/CIPs/tree/master/BiweeklyMeetings): do join and participate for discussions/PRs of significances to you.
## Editors Meeting Flow
- [x] **Triage/Review**: Some CIPs might fall out of grace or not get updated, a CIP that hasn’t seen activity for 3 months should be checked on, and appropriate action taken. Ex: did any of the recent changes obsolete current CIPs? Consider ‘Active’ -> ‘Obsolete’ transitions..
- [x] **Last Check**: Review of the PRIOR meetings Decisions - if no objection, apply change (effectively a two week lag from decision to action, as a grace period)
- [x] **New CIPs Review**: CIPs up for review should be looked over collectively, with discussion where needed. (on top of the asynchronous reviews)
PR -> ‘Draft’: Needs format + approval.
‘Draft’ -> ‘Proposed’: Needs a PLAN towards Active + implementation.
‘Proposed’ -> ‘Active’: Objective criteria as laid out observed, and consensus agreeing.
- [x] **Current Discussions**: What the current CIPs discussions are on social media / forums / Discord.
- [x] **Close**: Recap of actions taken and decisions. List the CIPs that are due for review. Distribution of the minutes via mailing list.
## January 12 2021 notes
**Attending Editors**: Matthias, Sebastien, Duncan, Frederic.
### Triage
N/A
### Last Check
#### Extended Metadata
([PR15](https://github.com/cardano-foundation/CIPs/pull/15) - potential CIP-0006)
**Frederic** - Some minor asks. It doesn't look like much has happened since last meeting.
**Duncan** - It's not something someone could implement unambiguously yet, because it's not described unambiguously.
**Sebastien** - There seem to be no rush to merge as-is. The asks in the comments are rather straightforward, recommend they be addressed prior to merge.
=> Ping @Gufmar to address final tweaks on Github.
#### On-chain stake pool operator to delegates communication
([PR44](https://github.com/cardano-foundation/CIPs/pull/44) - potential CIP-0012)
**S** - I feel the protocol described is fine to merge as-is from a tehnical perspective and fine as-is. There were some concerns regarding format, but my suggestion was to go for the simplest thing possible. I feel that's done, so happy. Only point unclear was about the uncoding for the data - the encoding used is UTF-8 - probably not the optimum way to pass long data - we could use CBOR to pass it on in a more optimized way.
**Duncan** - He's suggesting an array of text, each one at most 64 bytes... What would be the advantage of anything else (other than UTF-8)? I would keep it small.
**S** - Visually (UTF-8 encoded in Base64) would be smaller, but would be bigger at the byte level. I feel it adds complexity but no significant advantage.
**S** - Also I notice there is a conflict on the PR. They are modifying the master readme... Do we want to encourage authors editing the master readme file to add themselves? This wasn't part of CIP1...
**D** - I would say no. It will always cause more conflicts than it serves. (Fixed the conflict.)
=> **MERGING** now
#### Cardano URI Scheme
([PR30](https://github.com/cardano-foundation/CIPs/pull/30) - potential CIP-0013)
**S** - Matthias looked at this a while back - no objection I think
**Matthias** - I did then, it hasn't changed since December, is fine.
**S** - There was a request to add Bech32, that was done. I want to move and merge this, will add number now.
=> **MERGING** now
### Review
#### Shelley Protocol Parameters
([PR45](https://github.com/cardano-foundation/CIPs/pull/45) - potential CIP-xxxx)
**Kevin Hammond** - I updated this propsal and included ALL of the changes since Shelley into it. We now have a record for all param changes, appart maybe for 2.1 which may be mythical...
**D** - Did we establish (from Sam) re:one?
**K** - I can keep checking.
**Frederic** - Did we come to consensus wether this should be era-specific?
**K** - Up to Editors. What the Auditors wanted was a record of the initial settings, so the community can use that to base changes off, here was the rational for the choices for those params. What you're requesting is a chain tracking the changes. One thing you could do say the current params are the following, Here's a trace of all of the changes since the inception of Shelley plus a rationale for all of the changes. Which might be useful from a historic perspective.
**D** - We did discuss last time. I think the conclusion we came to, is that proposals changes should be as standalone - fitting with the CIP context of proposals, not _definitive_. There is no commitment of any party to implementation, so really they have to be independant. I think it makes sense to update it when the changes happen on-chain. So proposals should be separate CIPs, well-reasoned proposals. And this should be updated here when it changes on-chain. But if people want to make proposals that should be as a separate CIP. I think we requested to provide a template to propose a param change.
**K** - seems right, it feels that it might be on the Editor's role to provide that template.
**S** - I'm ok with no template. Else I recall as Duncan, I agree changes should be standalone CIPs. I'm ok with merging meanwhile.
**K** - What we could do is say any changes to Parameters should be submitted as a CIP including the name of the Parameters.
**D** - this should be made clear in this CIP that the change proposals should be as separate CIPs, not as changes to this one.
=> Moved to Last Check
#### HD Stake pool cold keys
([PR56](https://github.com/cardano-foundation/CIPs/pull/56) - potential CIP-xxxx)
**Michal** - We can add Rafael for the technical explanations. This proposal was added yesterday, but what we propose here is deterministic derivation of stake pool cold keys. We propose a derivation path as seen. Time is critical because we are trying to push this ledger app by the end of January. This approach will also enable to operate multiple stake pools from a single HW wallet.
**S** Is it feasible to derive a hardened key from a non-hardened parent?
**Rafael** not sure, maybe there are security considerations, thanks for avising.
**S** - I don't recall off the top of my head. I can look it up.
**M** - Tried looking on the BIP32 paper. We're going to have to spend more time into this to dispell concerns.
**R** - The non hardened Index was really for convenience but could be replaced by hardened for convenience. (see last paragraph in the PR).
**F** - the ask is to clarify the hardened feasiblity. Can we merge? Ok with numbering?
**R** - For number rationale it's in line with 1852 as a root index. The stakepools aren't logically related, it should make sense to add it as a distinct index.
**F** - As soon as we start diverging, it's opening the door to wild numberings for CIPs..
**Michal** - who will be responsible for validation on Hardened/non-hardened point?
**S** - I just looked it up now, in practice it's allowed but it means you'll only be able to derive the cold key index from a private key. So if you have a public key of the usecase then you won't be able to derive any child keys. Having usecase non-hardened is kinda pointless.
**R** - This was reserved for future cases. Someone may come up to proposal to derive non-hardened cold-key (for whatever reason).
**S** - Is that why the usecase field non-hardened?
**R** - Yes. In the rationale, we explain the non-hardened derivation usecase says that "in the future" it might be convienient to derive non-hardened cold keys. There could be future motivation for multiple non-hardened cases.
**S** - So in the future we might need a table for all the usecase values, are you suggesting all usecases be soft-derived rather than mixed (hard and soft)?
**R** - yeah
**S** - I can't see why we wouldn't have hard only for now, and future non-hardened spectrum
**R** - I can do that modification and point out that future usecases might take from the non-hardened cases (if it makes sense)
**Michal** - Can we agree you do not see any issue with this CIP and that there are no blockers on path as-is (beyond the hardened thing).
**F** - Even though there is a need to have this working from Ledger - there is no need to have CIP inclusion
**Michal** - There is no functional blocker, but if we implement it in some way but later change how the cold keys are derived then we could have multiple derivation paths.. We should work on a decision that is final.
**S** - Agree. I feel this is fine, including the numbering.
**F** - It would be merged on the 28th if we move this to lastcheck.
**D** - What does it mean when you have a level hardened and the sub-level non-hardened?
**R** - right now for the coldkey index being hardened there is no real point, but for the sake of future proofness. The premise was that other usecases for the coldkeys might arise in the future and those future usecases might find it suitable to have their childkeys non-hardened.
**D** - So 'some' usecase would have their (sub) cold keys non-hardened and some hardened. If 'usecase' is hardened then its hardened all the way own?
**R** - If you have a usecase hardened, then you cannot use the root key (purpose & cointype) & use that to derive the usecase and child keys because those are hardened. But if usecase is non-hardened, then you can derive those.
**D** - Is there a case in the future where you'd want to derive the 0th this as well as the 0th that?
**R** - Yes.
**M** - It sounds to me we are using 'usecase' as a different 'purpose'. It would be simpler without a 'usecase' and if you need a set of keys for a different Purpose then you pick a separate purpose...
**D** - ex: we have SPOs now, suppose in future we have a governance mechanism involving onchain voting through some indirect democracy, where you delegate to someone and they vote for you. To register as someone that folks delegate to, that would be much like registering as a SPO and we would want to manage the keys the same. Same pattern. If I want to register as many ppl they would all be different. I think Matthias is right. Keep usecase but only for things that are really the same. But otherwise, use a different purpose. so all the conditionals can be under a purpose.
**R** - Having the usecase hardened then?
**D** - Yes.
**R** - Agreed, and later (if somehow needed) we can still add non-hardened usecases.
=> Move to Last Check
#### Catalyst Registration transaction metadata format
([PR58](https://github.com/cardano-foundation/CIPs/pull/58) - potential CIP-xxxx)
- out of time -
### Discussions
- out of time -
### Close
**On Hold** “Curve proposal” (‘CIP7’) still awaiting legal followup
**On Hold** [PR15 - “Extended Metadata”](https://github.com/cardano-foundation/CIPs/pull/15) (tentative ‘CIP-0006’) - expecting authors to review and incorporate feedback, thn will merge.
=> Merge in two weeks: [PR45 - "Shelley Initial Parameters"](https://github.com/cardano-foundation/CIPs/pull/45) (tentative 'CIP-00xx')
=> Merge in two weeks: [PR56 - "HD stakepool cold keys"](https://github.com/cardano-foundation/CIPs/pull/56) (tentative 'CIP-00xx')
=> Merge **NOW**: [PR44 - "On-chain stake pool operator to delegates communication"](https://github.com/cardano-foundation/CIPs/pull/44) (‘CIP-0012’)
=> Merge **NOW**: [PR30 - "Cardano URI Scheme"](https://github.com/cardano-foundation/CIPs/pull/30) (‘CIP-0013’)
---
## Extra
### Current CIPs in the CIP repository and their status
|# |Title | Status |
| ----------------- |:----------------|:-------------------- |
| 1 | [CIP Process](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0001) | Active |
| 2 | [Coin Selection Algorithms for Cardano](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0002) | Draft |
| 3 | [Wallet key generation](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0003) | Draft |
| 4 | [Wallet Checksum](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0004) | Draft |
| 5 | [Common Bech32 Prefixes](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0005) | Draft |
| 7 | [Curve Pledge Benefit](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0007) | Draft |
| 8 | [Message Signing](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0008) | Draft |
| 10 | [Transaction Metadata Label Registry](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0010) | Draft |
| 11 | [Staking key chain for HD wallets](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0011) | Draft |
| 12 | [On-chain stake pool operator to delegates communication](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0012) | Draft |
| 13 | [Cardano URI Scheme](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0013) | Draft |
| 1852 | [HD Wallets for Cardano](https://github.com/cardano-foundation/CIPs/tree/master/CIP-1852) | Draft |
:bulb: - For more details about Statuses, refer to [CIP1](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0001).
### CIP creation process as a Sequence Diagram
_"Alice has a Cardano idea she'd like to build more formally":_
### Understanding CIPs further
[](https://www.youtube.com/watch?v=q7U10EfqXJw)
[](https://www.youtube.com/watch?v=dnw7k7VKVyo)
================================================
FILE: BiweeklyMeetings/2021-01-26.md
================================================
**Table of Contents:**
- [Summary](#summary)
- [Editors Meeting Flow](#editors-meeting-flow)
- [January 26 2021 notes](#january-26-2021-notes)
* [Triage](#triage)
* [Last Check](#last-check)
+ [PR15 - Extended Metadata](#Extended-Metadata)
+ [PR45 - Shelley Initial Parameters](#Shelley-Initial-Parameters)
+ [PR56 - HD Stake Pool Cold Keys](#HD-Stake-Pool-Cold-Keys)
* [Review](#review)
+ [PR58 - Catalyst Registration transaction metadata format](#Catalyst-Registration-transaction-metadata-format)
+ [PR61 - Update to CIP-0013](#Update-to-CIP-0013)
+ [PR62 - Update to CIP-0010](#Update-to-CIP-0010)
+ [PR57 - Key Serialization formats](#Key-Serialization-formats)
* [Discussions](#discussions)
* [Close](#close)
- [Extra](#extra)
* [Current CIPs in the CIP repository and their status](#current-cips-in-the-cip-repository-and-their-status)
* [CIP creation process as a Sequence Diagram](#cip-creation-process-as-a-sequence-diagram)
* [Understanding CIPs further](#understanding-cips-further)
## Summary
Rough writeup of 01/26/21 Editors meeting notes taken during that day's CIP meeting, to increase transparency and dialogue with the community regarding proposed changes, implementations and considerations.
<sub>_Notes might contain errors or miss pieces - call out issues as needed_
</sub>
Editors meetings are [public](https://www.crowdcast.io/cips-biweekly), [recorded](https://www.crowdcast.io/cips-biweekly) and [summarized](https://github.com/cardano-foundation/CIPs/tree/master/BiweeklyMeetings): do join and participate for discussions/PRs of significances to you.
## Editors Meeting Flow
- [x] **Triage/Review**: Some CIPs might fall out of grace or not get updated, a CIP that hasn’t seen activity for 3 months should be checked on, and appropriate action taken. Ex: did any of the recent changes obsolete current CIPs? Consider ‘Active’ -> ‘Obsolete’ transitions..
- [x] **Last Check**: Review of the PRIOR meetings Decisions - if no objection, apply change (effectively a two week lag from decision to action, as a grace period)
- [x] **New CIPs Review**: CIPs up for review should be looked over collectively, with discussion where needed. (on top of the asynchronous reviews)
PR -> ‘Draft’: Needs format + approval.
‘Draft’ -> ‘Proposed’: Needs a PLAN towards Active + implementation.
‘Proposed’ -> ‘Active’: Objective criteria as laid out observed, and consensus agreeing.
- [x] **Current Discussions**: What the current CIPs discussions are on social media / forums / Discord.
- [x] **Close**: Recap of actions taken and decisions. List the CIPs that are due for review. Distribution of the minutes via mailing list.
## January 26 2021 notes
**Attending Editors**: ~Matthias~, Sebastien, Duncan, Frederic.
### Triage
N/A
### Last Check
#### Extended Metadata
([PR15](https://github.com/cardano-foundation/CIPs/pull/15) - potential CIP-0006)
**Frederic** - No update from Markus - leaving as-is, reaching out to Markus.
=> Ping @Gufmar to address final tweaks on Github. Functionally on hold.
#### Cardano Parameters
([PR45](https://github.com/cardano-foundation/CIPs/pull/45) - potential CIP-0009)
**Frederic** - Ready to go but missing some structure. Consensus was this is ready to be merged.
**Duncan** - If it's simply the header, we should add this in and merge it. You can see the template for it, he added and removed it.
**Sebastien** - Ok to merge by me.
**D** - Remind the Catalyst group that this is not the PR for "proposing" but the informational one for updating. New CIPs for proposing parameter changes must be separate CIPs - conflicting CIPs can exist, but this should be the informational one.
**F** - What about the case where a parameter change happens but this CIP does not get updated?
**D** - Anyone would be able to come and push a PR with the appropriate change to update this.
=> **MERGING** pending internal discussion re: status.
#### HD Stake Pool Cold Keys
([PR56](https://github.com/cardano-foundation/CIPs/pull/56) - potential CIP-1853)
**S** - We requested changes last time.
**D** - There is a patch since last comments that we added - Last meeting we were looking at Hardened vs. non-hardened. Our conclusion was that the usecase fields should all be hardened: Now they are all hardened.
**S** - Approving.
=> **MERGING** now
### Review
#### Catalyst Registration transaction metadata format
([PR58](https://github.com/cardano-foundation/CIPs/pull/58) - potential CIP-0014)
**S** - This one is missing a CIP number but it's already deployed on mainnet. If someone wants to change working, this is already deployed. No opposition on wording tweaks.
**D** - Did anyone else reviewed this and double checked the description corresponds to reality?
**S** - No. This is just documenting what the Fund2 used 'in practice'. There were some test vectors and ideas but no formal writeup.
**D** - Can we get someone from Catalyst to review the CIP?
**S** - I'll ping on the topic and see. I also posted it in the Catalyst Slack channel as well.
=> to Last Check (to be merged next meeting)
#### Update to CIP-0013
([PR61](https://github.com/cardano-foundation/CIPs/pull/61) - Update to CIP-0013)
**Sebastien** - You may remember a while back we had that URI scheme and Robert wanted to add the support to create staking pool delegation through the URI scheme. We decided to setup what we had first, for the payment, but now this is adding another scheme. We want this so external websites can create URI links, that open accordingingly where they should. Since this is fairly related to the payment scheme, this should be bundled here, and might even later be expanded. This provides a source of truth that others can refer to.
**Robert** - The formal grammar was reworked, added another authority for doubleslash spent, (there was also a discussion for metadata, the URI could be further extended), we'd want the protocol to evolve, this PR is just for single pools to be added to the CIP itself.
**D** - Why is it that we want to custom URL schemes rather than a MIME type?
**S** - Yoroi is a browser extension. Whenever you select such a URL it'd open Yoroi (or Deadalus) appropriately..
**D** - Browsers have for decades been dealing with application associating with MIME types. This is my first time I see custom URI scheme - yet am not a web-dev. Presumably this works for mobile phones also. Is this common practive?
**S** - It used to be more contractors like mailto: and so on. Back then we could embed skype links etc. But it got too complicated and they created a whitelist of URI prefixes and not being on the list is no bueno. The recommended approach is to use an existing prefix which is why the URI scheme starts with 'Web+Cardano'- they still let you do it but in the namespace. Bitcoin (because it was created a while ago) managed to make it to the whitelist because it was created a while ago.
**D** - They still encourage you to do this rather than file + MIME types?
**S** - As far as I know. Have never seen MIME types used rather than this anywhere.
**D** - The QR codes?
**R** - QR codes are just enconding of URLs
**S** - Chrome has poor support for this but Firefox had. Unfortunately Chrome is winning the browser war. The support for the APIs are the bare minimum for the browser extensions / functionality to work, while Firefox has better thought out support. The only people that recommend specific setups are mobile apps, such as registering directly with your App: Instead of using a URI scheme, they link to a specific page and you have that specific page register with your app to check if it is installed, and if installed open the app...
**D** - Thanks for the digging into things.
**R** - This was explored in the closed [PR25](https://github.com/cardano-foundation/CIPs/pull/61) - Sebastien had answered it there. I'm a webdev, I integrate with websites and whatnot. Some schemes are more popular than the community realizes because of torrents and others... At least knowing we can rely on URI consistently would give the SPOs and end users at least one consistent option that is well supported.
**D** - One more Q: Can you use a combination of MIME/URI?
**S** - You cannot. It's not possible.
**D** - Why do we allow pool tickers given they aren't unique rather than their IDs?
**S** - The rationale is to accomodate for pool operators that have multiple pools with a common prefix. So they may want to have a URI to the common prefix and the wallet would be in charge of managing it.
=> to Last Check (to be merged next meeting)
#### Update to CIP-0010
([PR62](https://github.com/cardano-foundation/CIPs/pull/62) - Update to CIP-0010)
**F** - This is an update to the registry entry - not sure what this does.
**D** - It sounds like he wants CIP-0010 using a machine-readable format (on top of the existing human-readable format). He's given examples and a schema for how it should be added and implicitely the registry should fit that schema.
**S** - This seem to make sense in theory. Slightly concerned that these two (formats) will not sync up and we'll run into issues with one no longer matching the other? If we were to only pick one I would pick the machine-readable format and would avoid having both.
**D** - Avoiding duplication typically sensible.
=> Move to REVIEW for next meeting + reaching out to Author (Marek).
#### Key Serialization formats
([PR57](https://github.com/cardano-foundation/CIPs/pull/57) - potential CIP-xxxx)
**S** - Have not been able to review.
**D** - I've not properly reviewed yet. The intention here is to complement the prefixes CIP - this one here would be looking at the format of those keys for historical reference and documentation: This CIP is intent on describing what the FORMAT of keys is about - due to historical complexity and so no. That's from the 3 types of keys. Edd25519 keys, ordinary verification and signing keys, also the Jormagandr "extended keys" and later the "BIP32" keys. (One of those format should never have existed but Jormagandr added it anyways).
**S** - There is a good [Forum post](https://forum.cardano.org/t/message-signing-specification/41032/5) describing things, and it lists 4 formats.
**D** - We should be careful reviewing this, should flag to Matthias. The two recommended forms, and also for historical reasons the other ones still used by the older tools, intended to be never be used yet used as extended version by some tools... but not recommended to use. We should probably take this CIP over from here, this should be a good starting Draft.
=> Move to REVIEW for next meeting.
### Discussions
**D** - [PR55](https://github.com/cardano-foundation/CIPs/pull/55) looks like it's simple / ready to go and should be merged.
**S** - Let's merge it. (=> merging)
**F** - Mentions about using Tags in the repo if anyone has preference. Also regarding publicizing those meetings.
**D** - Also let's add [PR31](https://github.com/cardano-foundation/CIPs/pull/31) to next meeting. Looks ready to be merged even.
**R** - [PR61](https://github.com/cardano-foundation/CIPs/pull/61) has 2 reviews, but 1 of those isn't from an editor, are we awaiting for some other kind of review?
**D** - Correct, awaiting another Editor review. Will look into [PR61](https://github.com/cardano-foundation/CIPs/pull/61) and give it the green tick for next meeting.
### Close
**On Hold** “Curve proposal” (‘CIP7’) still awaiting legal followup
**On Hold** [PR15 - “Extended Metadata”](https://github.com/cardano-foundation/CIPs/pull/15) (tentative ‘CIP-0006’) - expecting last tweaks.
=> Merge **NOW**: [PR45 - "Initial Parameters"](https://github.com/cardano-foundation/CIPs/pull/45) ('CIP-0009')
=> Merge **NOW**: [PR56 - "HD stakepool cold keys"](https://github.com/cardano-foundation/CIPs/pull/56) ('CIP-1853')
=> _Last Check,_ Merge in two weeks: [PR58 - "Catalyst Registration transaction metadata format"](https://github.com/cardano-foundation/CIPs/pull/58) (tentative ‘CIP-0014’)
=> _Last Check,_ Merge in two weeks: [PR61 - Update to CIP-0013, adding delegation URI scheme](https://github.com/cardano-foundation/CIPs/pull/61)
---
## Extra
### Current CIPs in the CIP repository and their status
|# |Title | Status |
| ----------------- |:----------------|:-------------------- |
| 1 | [CIP Process](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0001) | Active |
| 2 | [Coin Selection Algorithms](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0002) | Draft |
| 3 | [Wallet key generation](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0003) | Draft |
| 4 | [Wallet Checksum](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0004) | Draft |
| 5 | [Common Bech32 Prefixes](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0005) | Draft |
| 7 | [Curve Pledge Benefit](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0007) | Draft |
| 8 | [Message Signing](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0008) | Draft |
| 9 | [Initial Parameters](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0009) | Draft |
| 10 | [Transaction Metadata Label Registry](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0010) | Draft |
| 11 | [Staking key chain for HD wallets](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0011) | Draft |
| 12 | [On-chain stake pool operator to delegates communication](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0012) | Draft |
| 13 | [Cardano URI Scheme](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0013) | Draft |
| 1852 | [HD Wallets for Cardano](https://github.com/cardano-foundation/CIPs/tree/master/CIP-1852) | Draft |
| 1853 | [HD Stake Pool Cold Keys](https://github.com/cardano-foundation/CIPs/tree/master/CIP-1853) | Draft |
:bulb: - For more details about Statuses, refer to [CIP1](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0001).
### CIP creation process as a Sequence Diagram
_"Alice has a Cardano idea she'd like to build more formally":_
### Understanding CIPs further
[](https://www.youtube.com/watch?v=q7U10EfqXJw)
[](https://www.youtube.com/watch?v=dnw7k7VKVyo)
================================================
FILE: BiweeklyMeetings/2021-02-09.md
================================================
**Table of Contents:**
- [Summary](#summary)
- [Editors Meeting Flow](#editors-meeting-flow)
- [February 9 2021 notes](#february-9-2021-notes)
* [Triage](#triage)
+ [PR15 - Extended Metadata](#Extended-Metadata)
* [Last Check](#last-check)
+ [PR58 - Catalyst Registration transaction metadata format](#Catalyst-Registration-transaction-metadata-format)
+ [PR61 - Update to CIP-0013](#Update-to-CIP-0013)
* [Review](#review)
+ [PR62 - Update to CIP-0010](#Update-to-CIP-0010)
+ [PR57 - Key Serialization formats](#Key-Serialization-formats)
* [Discussions](#discussions)
* [Close](#close)
- [Extra](#extra)
* [Current CIPs in the CIP repository and their status](#current-cips-in-the-cip-repository-and-their-status)
* [CIP creation process as a Sequence Diagram](#cip-creation-process-as-a-sequence-diagram)
* [Understanding CIPs further](#understanding-cips-further)
## Summary
Rough writeup of 2/9/21 Editors meeting notes taken during that day's CIP meeting, to increase transparency and dialogue with the community regarding proposed changes, implementations and considerations.
<sub>_Notes might contain errors or miss pieces - call out issues as needed_
</sub>
Editors meetings are [public](https://www.crowdcast.io/cips-biweekly), [recorded](https://www.crowdcast.io/cips-biweekly) and [summarized](https://github.com/cardano-foundation/CIPs/tree/master/BiweeklyMeetings): do join and participate for discussions/PRs of significances to you.
## Editors Meeting Flow
- [x] **Triage/Review**: Some CIPs might fall out of grace or not get updated, a CIP that hasn’t seen activity for 3 months should be checked on, and appropriate action taken. Ex: did any of the recent changes obsolete current CIPs? Consider ‘Active’ -> ‘Obsolete’ transitions..
- [x] **Last Check**: Review of the PRIOR meetings Decisions - if no objection, apply change (effectively a two week lag from decision to action, as a grace period)
- [x] **New CIPs Review**: CIPs up for review should be looked over collectively, with discussion where needed. (on top of the asynchronous reviews)
PR -> ‘Draft’: Needs format + approval.
‘Draft’ -> ‘Proposed’: Needs a PLAN towards Active + implementation.
‘Proposed’ -> ‘Active’: Objective criteria as laid out observed, and consensus agreeing.
- [x] **Current Discussions**: What the current CIPs discussions are on social media / forums / Discord.
- [x] **Close**: Recap of actions taken and decisions. List the CIPs that are due for review. Distribution of the minutes via mailing list.
## February 9 2021 notes
**Attending Editors**: ~Matthias~, Sebastien, Duncan, Frederic.
### Triage
#### Extended Metadata
([PR15](https://github.com/cardano-foundation/CIPs/pull/15) - potential CIP-0006)
**Frederic** - Work (and new commit) has happened since the last time, specific to the points raised for the PR.
**Markus** - (PR Author) - It took a long time, but I tried to address all comments - I reduced the proposals to a min verision of the Json schema. Although it might not fit all expectations - it should give some initial extended metadata and I hope we can merge and bring it to an actual proposal.
**Duncan** - I looked at it two weeks ago, what has changed?
**M** - There was a request to make it clear that this was stakepool metadata not on-chain metadata. I added explainer for the Cardano CLI used to generate signatures. What is missing here is what prefix should be used for the the extverification key: I don't thing we should define a special prefix just for this - Any thoughts? Should it be Bech32 format and if yes what prefix? I looked at other prefixes and didn't know if I should ppropose a specific/proper one for metadata or use ad-hoc..
**D** - I would follow the style of the CIP that logs all existing Bech32 prefixes... (CIP-0005)
**M** - I need a specific prefix for this one though.
**D** - What is the ExtV key, is it just an ordinary verifciation key?
**M** - Yea. I don't believe it should be anything special.
**D** - If you look at CIP 5 (which keeps track of the Bech32 prefixes), the style we use (to log all bech32 prefixes) is by purpose, not by format... pool operator verificationkey is a good example, ...
**M** - So you believe it's worth adding something like poolEVK or other
**D** - PoolMetada or PoolVK....
**M** - I'll try to add it to CIP 5.
**D** - just add it to your current PR, we can update CIP5 accordingly afterwards if that goes through.
**M** - I added the Json schema for this minimal version. What is missing is I want to change the PR Title, and since I am not the original Author...
**D** - I can change it right now, what to?
**M** - "CIP-0006 Pool Operator Extended Metadata".
**D** - Done.
**M** - Not sure if merged now it'll attract more people... Portals like PoolTool are able to implement it, and I hope SPOs start using this format. I addressed most comments, the only left was really the prefix thing. For me that should be it, but open to any questions or comments. There is also an example in there, in the interest of implementers, to see how it works. The Json schema is also pretty restricted, with min/max lengths, description of what fields should contain, logo as a URL to a file, with limit on File Size probably on the service-consuming application like PoolTool to decide how they want to handle a 30mb logo...
**D** - In the on-chain metadata, you got 'ExtVKey', did you intend that to be a 'raw verification key hash' or the actual verification key?
**M** - From the 3 new files, the public key for verification... The ExtVKey is what is generated with the new prefix... PoolMDVKey. It is put in the main metadata, a source of public information source so 3rd party applications can use it to link to verify. It's the actual key (not the hash). It's used to verify the signature that is in the main metadata file.
**D** - Do we describe anywhere what those verification steps are? It should be spelled out explicitely.
**M** - In the document, it says "The Operator first has to extend a data Json file and a data signature created by this CLI commands, and how it has to be published and the ExtVkey as field in the main metadata file... This is what he has to do one time to setup the extended metadata for that pool, and from there he can do with the CLI from there.
**D** - Because this is security-sensitive, let's be explicit: it should be unambiguous how to verify the content of the extended metadata.
"What is the format of the ExtV key / what is its content?" i.e. it's exactly a 32 byte ed25519 verification key. "What's the data we expect to find at the end of the extSig URL?" i.e. it is a 64 byte ed25519 signature. "How do we verify one?" through ordinary ed25519 verification using the known public key that's part of the normal metadata against (..) the data url we find at the end of the data signature url. What software implementing this specification needs to do.
**M** - I don't have the CLI command at the moment.
**D** - This isn't about the CLI but rather as to what needs to be done for the applications wanting to comply by this specification. Would have no problem merging once that is in.
=> to Last Check (to be merged next meeting)
### Last Check
#### Catalyst Registration transaction metadata format
([PR58](https://github.com/cardano-foundation/CIPs/pull/58) - potential CIP-0014)
**Sebastien** - I had the Catalyst team try and review this with the time they had, and got thumbs up emojis. Again that's not super indicative, but I got Samuel to review it and he said it was fine and added an extra part re: Fund3, as 3 will work slightly different from Fund2. There was one point still unresolved about the addition of a new key: "61286". It's still missing from this CIP, which is assumedly OK: it can be added at a later point. Tentatively reserved the number inside CIP10. Once we get a better format description of the reward payout (which is different from the registration payout anyways) we should be fine - this shouldn't block the merging of this CIP.
**F** - Minor comment re: the difference of the sidechain vs mainchain (..)
**S** - Agree to an extend, but good enough to merge as-is.
=> Merge **NOW**
#### Update to CIP-0013
([PR61](https://github.com/cardano-foundation/CIPs/pull/61) - Update to CIP-0013)
**F** - This is an update to CIP-0013
**S** - Nicolas made a competing separate PR (63?) to this one earlier today. PR61's author commented on Nico's PR, there hasn't been a clear resolution at this point, let's let both CIP authors agree on which standard to use from here.
=> To be reviewed the following meeting
### Review
#### Update to CIP-0010
([PR62](https://github.com/cardano-foundation/CIPs/pull/62) - Update to CIP-0010)
**Marek** - We are using the CIP10 in our scripts and were looking for a way to make it a bit easier for scripting, because parsing the markdown is challenging. This request here is to move it from human-readable to machine-readable. One suggestion from last meeting was to not keep two versions to prevent inconsistencies. I did that and moved everything to the json itself (except for the reserved values).
**S** - What we can do is merge the metadata registration CIP first, then rebase this one and add the missing parts to it (the metadata registration CIP modifies CIP10 as well.) I think this is fine to merge.
**D** - Approved this PR, also noted that we must figure out the order of the PR for the conversion.
=> Moved to Last Check (to be merged in two weeks)
#### Key Serialization Formats
([PR57](https://github.com/cardano-foundation/CIPs/pull/57) - potential CIP)
**F** - Luke was working on this, not sure if someone have been able to hop on this.
**D** - Others have been commenting and Luke has done some updates.. I haven't gotten around to looking at it recently.
**S** - Not familiar enough either.
=> Move to REVIEW for next meeting.
### Discussions
#### CIP7 - Curve Proposal parameter discussion
**Colin** - Hi all, I am following up on 'a0' from CIP7 - I have been speaking with Catalina and Shawn McMurdo. The actual spec was not one that research was comfortable with, they came back with a counter proposal that I talked Shawn through (and he was happy with that). Should this be an update to this CIP?
**D** - If it's more than a small tweak, it should be a separate CIP.
**C** - OK. It's a different approach: To use a flat curve pledge benefit entirely, removing the scaling.
**D** - It would be nice to include some of the supporting research, from you, Lars and the folks who have dug into this - good to include or reference if feasible.
**C** - Should be able to add in there.
#### PR64 - User-facing Asset Fingerprint - tentative CIP-0014
**D** - There's been lots of discussion happening on this PR already. This is one that Matthias is proposing but this is about the upcoming multiasset functionality and how we present assets to users. The basic suggestion is that despite the underlying solution that there is a policy hash, up to 32 bit hash for an asset per a single policy, Matthias suggestion here is - although the asset sub-identifier can in principle contain user element - we should make one opaque identifier and make it bech32. There are arguments wether it should be a hash or other: those identifers should be a non-readable blob. People in there are arguing about the details. This is related to the Metadata registry. This here is about how you display the information when you don't have the registry - Particularly good to get Sebastien to look into it.
**S** - I looked at the discussions and all pts I would have raised appear to have been raised...
### Close
**On Hold** ([PR61](https://github.com/cardano-foundation/CIPs/pull/61) - Update to CIP-0013)
=> Merge **NOW**: [PR58 - "Catalyst Registration transaction metadata format"](https://github.com/cardano-foundation/CIPs/pull/58) ('CIP-0015')
=> Review next meeting: [PR57 - "Key Serialization Formats"](https://github.com/cardano-foundation/CIPs/pull/57) (tentative ‘CIP-0016’)
=> _Last Check,_ Merge in two weeks: [PR62 - Update to CIP-0010](https://github.com/cardano-foundation/CIPs/pull/62) (Update to CIP-0010)
=> _Last Check,_ Merge in two weeks: [PR15 - "Stake Pool Extended Metadata"](https://github.com/cardano-foundation/CIPs/pull/15) (tentative ‘CIP-0006’)
---
## Extra
### Current CIPs in the CIP repository and their status
|# |Title | Status |
| ----------------- |:----------------|:-------------------- |
| 1 | [CIP Process](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0001) | Active |
| 2 | [Coin Selection Algorithms](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0002) | Draft |
| 3 | [Wallet key generation](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0003) | Draft |
| 4 | [Wallet Checksum](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0004) | Draft |
| 5 | [Common Bech32 Prefixes](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0005) | Draft |
| 7 | [Curve Pledge Benefit](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0007) | Draft |
| 8 | [Message Signing](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0008) | Draft |
| 9 | [Initial Parameters](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0009) | Draft |
| 10 | [Transaction Metadata Label Registry](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0010) | Draft |
| 11 | [Staking key chain for HD wallets](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0011) | Draft |
| 12 | [On-chain stake pool operator to delegates communication](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0012) | Draft |
| 13 | [Cardano URI Scheme](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0013) | Draft |
| 15 | [Catalyst Registration Transaction](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0015) | Draft |
| 1852 | [HD Wallets for Cardano](https://github.com/cardano-foundation/CIPs/tree/master/CIP-1852) | Draft |
| 1853 | [HD Stake Pool Cold Keys](https://github.com/cardano-foundation/CIPs/tree/master/CIP-1853) | Draft |
:bulb: - For more details about Statuses, refer to [CIP1](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0001).
### CIP creation process as a Sequence Diagram
_"Alice has a Cardano idea she'd like to build more formally":_
### Understanding CIPs further
[](https://www.youtube.com/watch?v=q7U10EfqXJw)
[](https://www.youtube.com/watch?v=dnw7k7VKVyo)
================================================
FILE: BiweeklyMeetings/2021-02-23.md
================================================
**Table of Contents:**
- [Summary](#summary)
- [Editors Meeting Flow](#editors-meeting-flow)
- [February 23 2021 notes](#february-23-2021-notes)
* [Triage](#triage)
* [Last Check](#last-check)
+ [PR15 - Extended Metadata](#Extended-Metadata)
+ [PR62 - Update to CIP-0010](#Update-to-CIP-0010)
* [Review](#review)
+ [PR61 - Update to CIP-0013](#Update-to-CIP-0013)
+ [PR57 - Key Serialization formats](#Key-Serialization-formats)
+ [PR66 - Fair Min Fees](#Fair-Min-Fees)
* [Discussions](#discussions)
+ [PR21 - Non-centralizing Rankings](#Non-Centralizing-Rankings)
+ [PR64 - User-Facing Asset Fingerprint](#User-Facing-Asset-Fingerprint)
* [Close](#close)
- [Extra](#extra)
* [Current CIPs in the CIP repository and their status](#current-cips-in-the-cip-repository-and-their-status)
* [CIP creation process as a Sequence Diagram](#cip-creation-process-as-a-sequence-diagram)
* [Understanding CIPs further](#understanding-cips-further)
## Summary
Rough writeup of 2/23/21 Editors meeting notes taken during that day's CIP meeting, to increase transparency and dialogue with the community regarding proposed changes, implementations and considerations.
<sub>_Notes might contain errors or miss pieces - call out issues as needed_
</sub>
Editors meetings are [public](https://www.crowdcast.io/cips-biweekly), [recorded](https://www.crowdcast.io/cips-biweekly) and [summarized](https://github.com/cardano-foundation/CIPs/tree/master/BiweeklyMeetings): do join and participate for discussions/PRs of significances to you.
## Editors Meeting Flow
- [x] **Triage/Review**: Some CIPs might fall out of grace or not get updated, a CIP that hasn’t seen activity for 3 months should be checked on, and appropriate action taken. Ex: did any of the recent changes obsolete current CIPs? Consider ‘Active’ -> ‘Obsolete’ transitions..
- [x] **Last Check**: Review of the PRIOR meetings Decisions - if no objection, apply change (effectively a two week lag from decision to action, as a grace period)
- [x] **New CIPs Review**: CIPs up for review should be looked over collectively, with discussion where needed. (on top of the asynchronous reviews)
PR -> ‘Draft’: Needs format + approval.
‘Draft’ -> ‘Proposed’: Needs a PLAN towards Active + implementation.
‘Proposed’ -> ‘Active’: Objective criteria as laid out observed, and consensus agreeing.
- [x] **Current Discussions**: What the current CIPs discussions are on social media / forums / Discord.
- [x] **Close**: Recap of actions taken and decisions. List the CIPs that are due for review. Distribution of the minutes via mailing list.
## February 23 2021 notes
**Attending Editors**: Matthias, Sebastien, Duncan, Frederic
### Triage
n/a
### Last Check
#### Extended Metadata
([PR15](https://github.com/cardano-foundation/CIPs/pull/15) - potential CIP-0006)
**Frederic** - I think this was good to go but there were some questions to be answered.
**Matthias** - We agreed to merge this as a draft, it being tweakable afterwards - fields and others can be on a separate PR or management...
**Sebastien** - Good to go.
=> Merge **NOW**
#### Update to CIP-0010
([PR62](https://github.com/cardano-foundation/CIPs/pull/62) - Update to CIP-0010)
**S** - The main thing with this one was dealing with the merge conflicts. I think that's done.
**F** - This needed to be rebased.
**S** - Good to be merged pending a rebase.
**M** - I skimmed through this but nothing major blocking.
=> Merging **NOW** / when rebased
### Review
#### Update to CIP-0013
([PR61](https://github.com/cardano-foundation/CIPs/pull/61) - Update to CIP-0013)
**F** - The separate competing [PR65](https://github.com/cardano-foundation/CIPs/pull/65)) is conflicting with this one.[PR61](https://github.com/cardano-foundation/CIPs/pull/61).
**Robert** - I was hoping that Nicolas would join us to discuss what he meant on how to resolve a conflict by using the stakepools as values rather than keys in a way that avoided an incompatibility between the UIR as he wanted to do it and expanding these links to multiple stake pools - he hasn't explained fully how it would work, and we're waiting to hear from him. Nicolas hasn't come back yet with a way to avoid that incompatibility. I do not believe there is a way of solving this imcompatibility. And really the best way to represent this all is a set of ordered pairs. And that's already the URIs with one value per discreet element: it makes sense for the pool names to be the keys and their portions to be the values. Since right now we have single pool links, none of them have values and there is only one of them, the suggestions he made weren't thinking about how it might expand for multiple pools. I was hoping the ideas could be simple enough to be explainable over github. This proposal was greenlighted a few weeks ago, and I would like to move this ahead if ok. This one is the most efficient representation that is least capacity for misinterpretation (and is easiest to parse and handle pathological cases). Not using ordered pairs would mean more complicated n-tuples.. you'd have a lot of complicated schemes. I feel Nico was trying to avoid headaches for the devs.
**S** - Nico cant join from time and due to load - but am sympathetic with his idea. Still I understand that tuples are a miss as well. Honestly either way is sub-par. The stakepool name as key does not make particular sense, but it's the easiest to implement as a shorthand. I know Nico feels reasonably strongly, I understand what he wants to do. For the 'stake' vs. 'delegate', I think Nico is right that we should use 'delegate' instead of 'stake'. It's only a few char diffs so 'delegate' is likley the most accurate.
**R** - So the way you would justify that for Stake pool links that aren't immediately used for delegation would be that you are "considering" delegating with them?
**S** - Yes.
**R** - What when Oracle pools come along? Won't people ask "why are Oracle pools called Oracles but Stake pools will be called delegate?" This might be another case where right now no convention might be ideal.
**S** - I don't see how Stake would be more accurate in either situation.
**M** - Isn't stakepool the most accurate?
**R** - That's what I have been saying, and is what I have been loading in the PR comments. I think the marketing ppl wants that their process suggest delegated POS - but we're talking about a different process here - this is a machine talking to another machine here.
**S** - I don't think that "Stake" is particularly accurate or representative. Rather Stake Pool...
**R** - I mainly feel strongly about the first discussion - switching value and pair. I'm happy to give way.
**F** - All for competing proposals - I feel this should be setup as last-check. The process of CIP review should be able to handle CIPs that some disagree with.
**S** - Fine with it - Just concerned about the commentorial explosion of "variations" of this... Although that might be unfortunate it might be unavoidable. We can deal with it then still.
**F** - This should probably be good to raise through the SPO Digest.
**R** - Great idea, but ba thing to wait for: the ammount of appathy for the relevance this has, has been astonishing. Let's not wait on feedback. As to PR65 - the [diff](https://github.com/nicarq/CIPs/commit/dd07c91017fec32700d94d65670565ffa076cd3a) is only a few lines and really not expanding.
**S** - If we merge both at the same time, there's a single URI scheme with tickername as the key - I am not sure it will matter as I don't think people are rushing to implement this anyways. Prpobably in the Yoroi extension mobile we will probably implement whatever Nicolas will be prefering. So the decision does not directly impact us. I say let's move both proposals in two weeks and we can adjust as needed. TLDR - mark both for merging.
=> Moved to Last Check (to be merged in two weeks) (+ PR65 to last check concurently).
#### Key Serialization Formats
([PR57](https://github.com/cardano-foundation/CIPs/pull/57) - potential CIP-0016)
**M** - This comes from discussions we had with Luke some time ago. We have basically many tools that operate on keys and they all have their own format of keys. Even more tools if you also consider Jormagandr at the time. I think it was just an attempt to come up with an increment on how to serialize the various parts of keys. Basically 'private keys' are a bunch of bytes, but when you start using extended private keys for hierarchical derivations as we do in wallet, there are other parts to keys such as the chaincode, which explains how you should serialize these things together... So Chaincode and private key instead of just private key. This here is capturing what is currently done and putting it in a CIP so that other ppl can reference it or reuse it.
**S** - I read through and it is fine. There is however a long comment in there that hasn't been addressed.
**M** - That comment is mostly about CIP5 though a bit irrelevant to the proposal maybe.
**S** - If you could write down what you just said, it would be stisfactory. (**M** We should definately address it).
**D** - Is this about BECH32 prefix hould be those sort of physical things or they should be about roles?
=> Moved to Last Check (pending a comment reply by **M**)
#### Fair Min Fees
([PR66](https://github.com/cardano-foundation/CIPs/pull/66) - potential CIP-0017)
**F** - This is about Minimum fixed pool fees.
**S** - I thing the same people that looked into the Curved pledge pool feel would be needed here since it changes profitability and so on... (Colin / Kevin)
**D** - This is a veery technical one and changing the fee changes some attacks on the system. There needs careful analysis by the right individual.
=> Flag to relevant individuals and align a review with their help
### Discussions
#### Non Centralizing Rankings
([PR21](https://github.com/cardano-foundation/CIPs/pull/21) - potential CIP-0018)
**R** - I didn't want to see this die - as I understand it, and I am not the one who has compared and contrasted the ranking equations, this is incorporating an exponentially decaying average of pool results and with their potential as it already exists in the ranking algorithm, which would produce a mixture of Large and small pools at the top of the ranks. As someone whose pool has been struggling to survive, this could breakup the aggregation of stake within the longtime inertially saturated pools. Some people don't see it as a problem, some people conceived it as a nash equilibrium. I think the conception of a nash equilibrium might actually be working against Cardano rather than for it. I think I laid that out much in the comment, but this reflects the general apathy mentionned earlier: The pools, particularly the small pools, might feel there is a wall between the developers and the pools themnselves. And the smaller pools opinions should be included in those conversations. So maybe this would be a good proposal to bring up for SPO Digest.
**D** - My opinion is that often people make the request to the wrong place. I hear your complaints but the change needed is to the actual infrastructure. Not shooting the messengers, but rather requesting/campaigning for changing to the actual incentives of the system. This is what that CIP was actually doing. Shawn also wrote a separate CIP about actually changing the incentives (Curve Pledge) and it may make sense of reevaluating wether the ranking actually reflect the proper underlying incentives of the system. That's worth evaluating, but the bigger issues such as "what is the value of k" the complaints ought to be there... Specificlally on the ranking that is very relevant to consider that the expectation of k winners and we are not certain of who the winners will be - we shouldn't have a cliff edge at k, we should probably have a slopeoff. This CIP here tries to get rid of the assumption that there is k successfull pools. Which doesn't do anything to the underlying incentives. And the mathematics shows that this is what happens with the math setup. If we want 1000 SP then we need to set k as 1000. Suggest dirrecting the energy in the right place.
**R** - What I think we need is a smooth edge, not a cliff edge at k.
**D** - I agree with you. It would be perfectly reasonable to have one such CIP written. I was holding off on having conversations with Researchers... I haven't actually dug into the actual propopasals from thinking about removing the assumpitons. .. But yes, changing about which the k winners are and a smooth distribution in some grounded way..
**R** - It should derive from the system itself.
**D** - Can we check in with Shawn and see if he wants to retire it or continue it in this current form?
=> Flag to relevant individuals (Shawn, Researchers) add to review for next meeting.
#### User-Facing Asset Fingerprint
([PR64](https://github.com/cardano-foundation/CIPs/pull/64) - potential CIP-0014)
**S** - This is already implemented in Cardano wallet and will be included in the March 1st HF. I would prefer this be merged sooner than later. I have read throuh and there doesn't seem to be strong opposition to it despite the one way nature of it. Looks like we will be implementing this in Deadalus and Yoroi also.
**M** - There are also a few SPOs waiting on that also.
**S** - The only concern was about using the Bech32 vs Bech32m - the newly modified bech32...
**M** - I think bech32 is just fine since we have been using it everywhere. And if we want to change it to bech32m it should be a more hollistic approach.
**D** - I agree if we can. What was the major change to that PR? The digest length down to 20?
**M** - Yes, and the fingerprint is not an input format, only meant for users, not machines. I tried to make it clear that for uniqueness you really want to use policyID. I also added test vectors - I feel this is a rather complete CIP as-is.
=> Moving to Last Check
### Close
=> Merge **NOW**: [PR15 - "Stake Pool Extended Metadata"](https://github.com/cardano-foundation/CIPs/pull/15) (tentative ‘CIP-0006’)
=> Merge **NOW**: [PR62 - Update to CIP-0010](https://github.com/cardano-foundation/CIPs/pull/62) Update to CIP-0010
=> Review next meeting: [PR57 - "Key Serialization Formats"](https://github.com/cardano-foundation/CIPs/pull/57) (tentative ‘CIP-0016’)
=> Review next meeting: [PR66 - "Fair Min Fees"](https://github.com/cardano-foundation/CIPs/pull/66) (tentative 'CIP-0017')
=> _Last Check,_ Merge in two weeks: [PR61 - Update to CIP-0013](https://github.com/cardano-foundation/CIPs/pull/61) - Update to CIP-0013
=> _Last Check,_ Merge in two weeks: [PR65 - Update to CIP-0013](https://github.com/cardano-foundation/CIPs/pull/65) - Update to CIP-0013
=> _Last Check,_ Merge in two weeks: [PR64 - User-facing asset fingerprint](https://github.com/cardano-foundation/CIPs/pull/64) - (tentative ‘CIP-0014')
---
## Extra
### Current CIPs in the CIP repository and their status
|# |Title | Status |
| ----------------- |:----------------|:-------------------- |
| 1 | [CIP Process](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0001) | Active |
| 2 | [Coin Selection Algorithms](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0002) | Draft |
| 3 | [Wallet key generation](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0003) | Draft |
| 4 | [Wallet Checksum](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0004) | Draft |
| 5 | [Common Bech32 Prefixes](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0005) | Draft |
| 6 | [Stake Pool Extended Metadata](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0006) | Draft |
| 7 | [Curve Pledge Benefit](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0007) | Draft |
| 8 | [Message Signing](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0008) | Draft |
| 9 | [Initial Parameters](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0009) | Draft |
| 10 | [Transaction Metadata Label Registry](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0010) | Draft |
| 11 | [Staking key chain for HD wallets](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0011) | Draft |
| 12 | [On-chain SPO-to-delegates communication](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0012) | Draft |
| 13 | [Cardano URI Scheme](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0013) | Draft |
| 15 | [Catalyst Registration Transaction](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0015) | Draft |
| 1852 | [HD Wallets for Cardano](https://github.com/cardano-foundation/CIPs/tree/master/CIP-1852) | Draft |
| 1853 | [HD Stake Pool Cold Keys](https://github.com/cardano-foundation/CIPs/tree/master/CIP-1853) | Draft |
:bulb: - For more details about Statuses, refer to [CIP1](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0001).
### CIP creation process as a Sequence Diagram
_"Alice has a Cardano idea she'd like to build more formally":_
### Understanding CIPs further
[](https://www.youtube.com/watch?v=q7U10EfqXJw)
[](https://www.youtube.com/watch?v=dnw7k7VKVyo)
================================================
FILE: BiweeklyMeetings/2021-03-16.md
================================================
**Table of Contents:**
- [Summary](#summary)
- [Editors Meeting Flow](#editors-meeting-flow)
- [March 16 2021 notes](#march-16-2021-notes)
* [Triage](#triage)
+ [PR62 - Update to CIP-0010](#Update-to-CIP-0010)
* [Last Check](#last-check)
+ [PR61 - Update to CIP-0013](#Update-to-CIP-0013)
+ [PR65 - Update to CIP-0013](#Update-to-CIP-0013)
+ [PR64 - User-facing Asset Fingerprint](#User-facing-Asset-Fingerprint)
* [Review](#review)
+ [PR57 - Key Serialization formats](#Key-Serialization-formats)
+ [PR66 - Fair Min Fees](#Fair-Min-Fees)
+ [PR21 - Non-centralizing Rankings](#Non-Centralizing-Rankings)
* [Discussions](#discussions)
* [Close](#close)
- [Extra](#extra)
* [Current CIPs in the CIP repository and their status](#current-cips-in-the-cip-repository-and-their-status)
* [CIP creation process as a Sequence Diagram](#cip-creation-process-as-a-sequence-diagram)
* [Understanding CIPs further](#understanding-cips-further)
## Summary
Rough writeup of 3/16/21 Editors meeting notes taken during that day's CIP meeting, to increase transparency and dialogue with the community regarding proposed changes, implementations and considerations.
<sub>_Notes might contain errors or miss pieces - call out issues as needed_
</sub>
Editors meetings are [public](https://www.crowdcast.io/cips-biweekly), [recorded](https://www.crowdcast.io/cips-biweekly) and [summarized](https://github.com/cardano-foundation/CIPs/tree/master/BiweeklyMeetings): do join and participate for discussions/PRs of significances to you.
## Editors Meeting Flow
- [x] **Triage/Review**: Some CIPs might fall out of grace or not get updated, a CIP that hasn’t seen activity for 3 months should be checked on, and appropriate action taken. Ex: did any of the recent changes obsolete current CIPs? Consider ‘Active’ -> ‘Obsolete’ transitions..
- [x] **Last Check**: Review of the PRIOR meetings Decisions - if no objection, apply change (effectively a two week lag from decision to action, as a grace period)
- [x] **New CIPs Review**: CIPs up for review should be looked over collectively, with discussion where needed. (on top of the asynchronous reviews)
PR -> ‘Draft’: Needs format + approval.
‘Draft’ -> ‘Proposed’: Needs a PLAN towards Active + implementation.
‘Proposed’ -> ‘Active’: Objective criteria as laid out observed, and consensus agreeing.
- [x] **Current Discussions**: What the current CIPs discussions are on social media / forums / Discord.
- [x] **Close**: Recap of actions taken and decisions. List the CIPs that are due for review. Distribution of the minutes via mailing list.
## March 16 2021 notes
**Attending Editors**: Matthias, Sebastien, Duncan, Frederic
### Triage
#### Update to CIP-0010
- ([PR62](https://github.com/cardano-foundation/CIPs/pull/62) - Update to CIP-0010)
**F** - I think I might have been getting the request for rebase wrong, is this correct/good to go here?
**M** - This PR wants to keep things separate = moving content to a different location, out of the readme file. This PR makes the registry easily parseable by tools, instead of having to manually parse a readme. The dynamic one you want to have in a structured format. Checking in as it was rebased last week... Looks good.
=> Merging **NOW**
### Last Check
#### Update to CIP-0013
([PR61](https://github.com/cardano-foundation/CIPs/pull/61) and [PR65](https://github.com/cardano-foundation/CIPs/pull/65) - Updates to CIP-0013)
**Frederic** - Both 65 and 61 were setup as "Last Check". To be merged this week if feasible.
**Robert** - I don't know what PR65 woud actually do: There's really only been one technical description of how the SPO links would be added to the URI scheme. PR65 is incomplete. So CIP-0013 should be the one that has been outlined: PR61. Suggesting PR65 as a separate CIP would be logical.
**Duncan** - Can we go over the differences between PR61 and PR65?
**R** - The resistance that Nick had to using the StakePool names as keys also would prevent them from having values. So when the StakePool link
gitextract_2tm41wvl/ ├── .gitattributes ├── .github/ │ ├── CIP-TEMPLATE.md │ ├── CPS-TEMPLATE.md │ ├── CPS-VALIDATION.md │ ├── schemas/ │ │ └── cps-header.schema.json │ ├── scripts/ │ │ └── validate-cps.py │ └── workflows/ │ ├── cip10-validation.yaml │ └── cps-validation.yaml ├── BiweeklyMeetings/ │ ├── 2020-07-01.md │ ├── 2020-07-15.md │ ├── 2020-08-04.md │ ├── 2020-08-11.md │ ├── 2020-08-25.md │ ├── 2020-09-08.md │ ├── 2020-09-22.md │ ├── 2020-10-06.md │ ├── 2020-10-20.md │ ├── 2020-11-03.md │ ├── 2020-11-17.md │ ├── 2020-12-08.md │ ├── 2021-01-12.md │ ├── 2021-01-26.md │ ├── 2021-02-09.md │ ├── 2021-02-23.md │ ├── 2021-03-16.md │ ├── 2021-03-30.md │ ├── 2021-04-13.md │ ├── 2021-04-27.md │ ├── 2021-05-11.md │ ├── 2021-05-25.md │ ├── 2021-06-08.md │ ├── 2021-06-29.md │ ├── 2021-07-20.md │ ├── 2021-08-03.md │ ├── 2021-08-17.md │ ├── 2021-09-07.md │ ├── 2021-09-21.md │ ├── 2021-10-05.md │ ├── 2021-10-19.md │ ├── 2021-11-09.md │ ├── 2021-11-23.md │ ├── 2021-12-07.md │ ├── 2021-12-21.md │ ├── 2022-01-11.md │ ├── 2022-01-25.md │ ├── 2022-02-15.md │ ├── 2022-03-01.md │ ├── 2022-03-15.md │ ├── 2022-04-05.md │ ├── 2022-04-12.md │ ├── 2022-05-10.md │ ├── 2022-05-24.md │ ├── 2022-06-07.md │ ├── 2022-06-28.md │ ├── 2022-07-05.md │ ├── 2022-07-19.md │ ├── 2022-08-02.md │ ├── 2022-08-16.md │ └── 2022-09-06.md ├── CIP-0001/ │ ├── CIP-0001.md │ └── README.md ├── CIP-0002/ │ ├── CIP-0002.md │ └── README.md ├── CIP-0003/ │ ├── Byron.md │ ├── CIP-0003.md │ ├── Icarus.md │ ├── Ledger_BitBox02.md │ └── README.md ├── CIP-0004/ │ ├── CIP-0004.md │ └── README.md ├── CIP-0005/ │ ├── CIP-0005.md │ └── README.md ├── CIP-0006/ │ ├── CIP-0006.md │ ├── README.md │ └── schema.json ├── CIP-0007/ │ ├── CIP-0007.md │ ├── README.md │ └── rewards.php ├── CIP-0008/ │ ├── CIP-0008.md │ └── README.md ├── CIP-0009/ │ ├── CIP-0009.md │ └── README.md ├── CIP-0010/ │ ├── CIP-0010.md │ ├── README.md │ ├── registry.json │ └── registry.schema.json ├── CIP-0011/ │ ├── CIP-0011.md │ └── README.md ├── CIP-0012/ │ ├── CIP-0012.md │ ├── README.md │ └── schema.json ├── CIP-0013/ │ ├── CIP-0013.md │ └── README.md ├── CIP-0014/ │ ├── CIP-0014.md │ └── README.md ├── CIP-0015/ │ ├── CIP-0015.md │ ├── README.md │ ├── schema.cddl │ └── test-vector.md ├── CIP-0016/ │ ├── CIP-0016.md │ └── README.md ├── CIP-0017/ │ ├── CIP-0017.json │ ├── CIP-0017.md │ └── README.md ├── CIP-0018/ │ ├── CIP-0018.md │ └── README.md ├── CIP-0019/ │ ├── CIP-0019-byron-addresses.cddl │ ├── CIP-0019-cardano-addresses.abnf │ ├── CIP-0019.md │ └── README.md ├── CIP-0020/ │ ├── CIP-0020.md │ └── README.md ├── CIP-0021/ │ ├── CIP-0021.md │ └── README.md ├── CIP-0022/ │ ├── CIP-0022.md │ └── README.md ├── CIP-0023/ │ ├── CIP-0023.md │ ├── README.md │ └── minfees.php ├── CIP-0024/ │ ├── CIP-0024.md │ └── README.md ├── CIP-0025/ │ ├── CIP-0025.md │ ├── README.md │ └── cddl/ │ ├── version_1.cddl │ └── version_2.cddl ├── CIP-0026/ │ ├── README.md │ └── schema.json ├── CIP-0027/ │ ├── CIP-0027.md │ └── README.md ├── CIP-0028/ │ └── README.md ├── CIP-0029/ │ ├── CIP-0029.md │ ├── README.md │ ├── phase-1-monetary-scripts.cddl │ └── phase-1-monetary-scripts.json ├── CIP-0030/ │ ├── README.md │ └── extensions-register.md ├── CIP-0031/ │ └── README.md ├── CIP-0032/ │ └── README.md ├── CIP-0033/ │ └── README.md ├── CIP-0034/ │ ├── README.md │ ├── registry.json │ └── schema.json ├── CIP-0035/ │ └── README.md ├── CIP-0036/ │ ├── README.md │ ├── schema.cddl │ └── test-vector.md ├── CIP-0037/ │ └── README.md ├── CIP-0040/ │ └── README.md ├── CIP-0042/ │ └── README.md ├── CIP-0045/ │ └── README.md ├── CIP-0049/ │ └── README.md ├── CIP-0050/ │ └── README.md ├── CIP-0052/ │ ├── README.md │ └── Tx-spec.md ├── CIP-0054/ │ └── README.md ├── CIP-0055/ │ └── README.md ├── CIP-0057/ │ ├── README.md │ └── schemas/ │ ├── README.md │ ├── plutus-blueprint-argument.json │ ├── plutus-blueprint-parameter.json │ ├── plutus-blueprint.json │ ├── plutus-builtin.json │ └── plutus-data.json ├── CIP-0058/ │ └── README.md ├── CIP-0059/ │ ├── README.md │ └── feature-table.md ├── CIP-0060/ │ ├── README.md │ └── cddl/ │ ├── version-1.cddl │ ├── version-2.cddl │ └── version-3.cddl ├── CIP-0067/ │ ├── README.md │ ├── registry.json │ └── registry.schema.json ├── CIP-0068/ │ ├── README.md │ ├── extension_boilerplate.md │ └── ref_impl/ │ ├── README.md │ ├── offchain.ts │ └── onchain.hs ├── CIP-0069/ │ └── README.md ├── CIP-0071/ │ ├── README.md │ └── example/ │ ├── voting.html │ └── voting.js ├── CIP-0072/ │ ├── README.md │ ├── version_2.0.0_offchain.json │ ├── version_2.0.0_onchain.cddl │ └── version_2.0.0_onchain.json ├── CIP-0074/ │ └── README.md ├── CIP-0075/ │ ├── FairStakepoolRewards.xlsx │ ├── README.md │ └── UnsaturatedPledgeBenefitPenalty.xlsx ├── CIP-0080/ │ └── README.md ├── CIP-0082/ │ ├── ImprovedRewardsSchemeParameters.xlsx │ └── README.md ├── CIP-0083/ │ ├── README.md │ ├── codesamples/ │ │ ├── democode-BASH.sh │ │ ├── democode-NODEJS.js │ │ ├── democode-PHP.php │ │ ├── democode-WEB.js │ │ ├── encrypted-message-metadata.json │ │ └── normal-message-metadata.json │ └── format.cddl ├── CIP-0084/ │ └── README.md ├── CIP-0085/ │ └── README.md ├── CIP-0086/ │ ├── README.md │ └── cddl/ │ ├── version_1.cddl │ └── version_2.cddl ├── CIP-0088/ │ ├── CIPs/ │ │ ├── 0025/ │ │ │ ├── CIP25_v1.cddl │ │ │ ├── CIP25_v1.json │ │ │ ├── CIP25_v1.schema.json │ │ │ └── README.md │ │ ├── 0026/ │ │ │ ├── CIP26_v1.cddl │ │ │ ├── CIP26_v1.json │ │ │ ├── CIP26_v1.schema.json │ │ │ └── README.md │ │ ├── 0027/ │ │ │ ├── CIP27_v1.cddl │ │ │ ├── CIP27_v1.json │ │ │ ├── CIP27_v1.schema.json │ │ │ └── README.md │ │ ├── 0048/ │ │ │ ├── CIP48_v1.cddl │ │ │ └── README.md │ │ ├── 0060/ │ │ │ ├── CIP60_v1.cddl │ │ │ └── README.md │ │ ├── 0068/ │ │ │ ├── CIP68_v1.cddl │ │ │ ├── CIP68_v1.json │ │ │ ├── CIP68_v1.schema.json │ │ │ └── README.md │ │ ├── 0086/ │ │ │ ├── CIP86_v1.cddl │ │ │ └── README.md │ │ ├── README.md │ │ ├── common/ │ │ │ ├── CIP88_Master_v1.cddl │ │ │ ├── CIP88_Master_v2.cddl │ │ │ ├── CIP88_Master_v2.example.json │ │ │ ├── README.md │ │ │ ├── Token-Project-Details_v1.md │ │ │ ├── token-project-details_v1.cddl │ │ │ ├── token-project-details_v1.schema.json │ │ │ └── uri-array.schema.json │ │ └── template/ │ │ ├── CIPXXXX_v1.cddl │ │ ├── CIPXXXX_v1.json │ │ ├── CIPXXXX_v1.schema.json │ │ └── README.md │ └── README.md ├── CIP-0089/ │ └── README.md ├── CIP-0091/ │ └── README.md ├── CIP-0093/ │ ├── README.md │ └── json/ │ └── payload-schema-v1.json ├── CIP-0094/ │ └── README.md ├── CIP-0095/ │ └── README.md ├── CIP-0099/ │ └── README.md ├── CIP-0100/ │ ├── README.md │ ├── cip-0100.common.jsonld │ ├── cip-0100.common.schema.json │ ├── example.body.json │ ├── example.body.nq │ ├── example.json │ └── test-vector.md ├── CIP-0101/ │ └── README.md ├── CIP-0102/ │ └── README.md ├── CIP-0103/ │ └── README.md ├── CIP-0104/ │ └── README.md ├── CIP-0105/ │ ├── README.md │ ├── test-vectors/ │ │ ├── test-vector-1.md │ │ ├── test-vector-2.md │ │ ├── test-vector-3.md │ │ └── test-vector-4.md │ └── test-vectors.md ├── CIP-0106/ │ └── README.md ├── CIP-0107/ │ └── README.md ├── CIP-0108/ │ ├── README.md │ ├── cip-0108.common.jsonld │ ├── cip-0108.common.schema.json │ ├── examples/ │ │ ├── no-confidence.body.jsonld │ │ ├── no-confidence.body.nq │ │ ├── no-confidence.jsonld │ │ ├── treasury-withdrawal.body.jsonld │ │ ├── treasury-withdrawal.body.nq │ │ └── treasury-withdrawal.jsonld │ └── test-vector.md ├── CIP-0109/ │ └── README.md ├── CIP-0110/ │ └── README.md ├── CIP-0112/ │ └── README.md ├── CIP-0114/ │ ├── README.md │ ├── registry.json │ └── registry.schema.json ├── CIP-0115/ │ └── README.md ├── CIP-0116/ │ ├── README.md │ ├── cardano-babbage.json │ ├── cardano-conway.json │ └── changelog.md ├── CIP-0117/ │ └── README.md ├── CIP-0118/ │ └── README.md ├── CIP-0119/ │ ├── README.md │ ├── cip-0119.common.jsonld │ ├── cip-0119.common.schema.json │ ├── examples/ │ │ └── drep.jsonld │ └── test-vector.md ├── CIP-0120/ │ ├── README.md │ ├── examples/ │ │ ├── malicious-consitution/ │ │ │ └── cardano-constitution-5.txt │ │ └── ryan-consitution/ │ │ └── cardano-constitution-0.txt │ └── test-vector.md ├── CIP-0121/ │ └── README.md ├── CIP-0122/ │ └── README.md ├── CIP-0123/ │ └── README.md ├── CIP-0124/ │ ├── README.md │ └── cddl/ │ ├── version_1.cddl │ └── version_2.cddl ├── CIP-0127/ │ └── README.md ├── CIP-0128/ │ └── README.md ├── CIP-0129/ │ └── README.md ├── CIP-0132/ │ └── README.md ├── CIP-0133/ │ └── README.md ├── CIP-0134/ │ └── README.md ├── CIP-0135/ │ └── README.md ├── CIP-0136/ │ ├── README.md │ ├── cip-136.common.jsonld │ ├── cip-136.common.schema.json │ ├── examples/ │ │ ├── parameter-change-abstain.body.jsonld │ │ ├── parameter-change-abstain.body.nq │ │ ├── parameter-change-abstain.jsonld │ │ ├── treasury-withdrawal-unconstitutional.body.jsonld │ │ ├── treasury-withdrawal-unconstitutional.body.nq │ │ └── treasury-withdrawal-unconstitutional.jsonld │ └── test-vector.md ├── CIP-0137/ │ └── README.md ├── CIP-0138/ │ └── README.md ├── CIP-0139/ │ ├── Query_Layer_API_Comparison.md │ ├── README.md │ ├── cip-0144.md │ ├── endpoints.md │ ├── json-rpc.json │ ├── open-api.json │ ├── query-layer.json │ └── ts-api.md ├── CIP-0140/ │ ├── .gitignore │ ├── README.md │ ├── flake.nix │ └── peras.agda-lib ├── CIP-0141/ │ └── README.md ├── CIP-0142/ │ └── README.md ├── CIP-0143/ │ └── README.md ├── CIP-0146/ │ └── README.md ├── CIP-0149/ │ └── README.md ├── CIP-0150/ │ ├── README.md │ └── stats.json ├── CIP-0151/ │ ├── CIP88_Master_v2.cddl │ ├── CIP88_Master_v2.example.json │ └── README.md ├── CIP-0152/ │ └── README.md ├── CIP-0153/ │ └── README.md ├── CIP-0155/ │ ├── README.md │ ├── registry.json │ └── registry.schema.json ├── CIP-0156/ │ └── README.md ├── CIP-0158/ │ └── README.md ├── CIP-0159/ │ └── README.md ├── CIP-0160/ │ └── README.md ├── CIP-0161/ │ ├── README.md │ └── graph/ │ ├── NhandNa.py │ ├── extended_error_series_corrected.csv │ ├── scenario-cost-cross-thresholds.py │ ├── scenario_cost_praos_vs_phalanx-full-scenarios.py │ ├── scenario_cost_praos_vs_phalanx.py │ ├── settlement-time-phalanx.py │ ├── settlement-time-praos.py │ ├── settlement-time-without-grinding.py │ └── vdf_benches.py ├── CIP-0162/ │ └── README.md ├── CIP-0163/ │ └── README.md ├── CIP-0164/ │ ├── README.md │ └── SUMMARY.md ├── CIP-0165/ │ ├── README.md │ ├── format/ │ │ ├── format.ksy │ │ └── scls_file.html │ └── namespaces/ │ ├── README.md │ ├── blocks_v0.cddl │ ├── gov_committee_v0.cddl │ ├── gov_constitution_v0.cddl │ ├── gov_pparams_v0.cddl │ ├── gov_proposals_v0.cddl │ ├── nonces_v0.cddl │ ├── pool_stake_v0.cddl │ ├── snapshots_v0.cddl │ └── utxo_v0.cddl ├── CIP-0167/ │ └── README.md ├── CIP-0170/ │ ├── README.md │ ├── example-credential-chain.cesr │ ├── example-revocation-event.cesr │ ├── version_1.cddl │ ├── version_1.json │ └── vlei-cardano-metadata-signer-credential.json ├── CIP-0171/ │ └── README.md ├── CIP-0176/ │ └── README.md ├── CIP-0381/ │ └── README.md ├── CIP-1694/ │ ├── README.fr.md │ └── README.md ├── CIP-1852/ │ ├── CIP-1852.md │ └── README.md ├── CIP-1853/ │ ├── CIP-1853.md │ └── README.md ├── CIP-1854/ │ ├── CIP-1854.md │ └── README.md ├── CIP-1855/ │ ├── CIP-1855.md │ └── README.md ├── CIP-9999/ │ └── README.md ├── CODE_OF_CONDUCT.md ├── CONTRIBUTING ├── CPS-0003/ │ └── README.md ├── CPS-0005/ │ └── README.md ├── CPS-0007/ │ └── README.md ├── CPS-0008/ │ └── README.md ├── CPS-0009/ │ └── README.md ├── CPS-0010/ │ └── README.md ├── CPS-0011/ │ └── README.md ├── CPS-0012/ │ └── README.md ├── CPS-0013/ │ └── README.md ├── CPS-0014/ │ └── README.md ├── CPS-0016/ │ └── README.md ├── CPS-0017/ │ └── README.md ├── CPS-0018/ │ └── README.md ├── CPS-0020/ │ └── README.md ├── CPS-0021/ │ ├── CPD/ │ │ ├── README.md │ │ └── graph/ │ │ ├── forking_probabilities.py │ │ ├── mixing_probabilities.py │ │ ├── scenario_cost-graph.py │ │ ├── scenario_cpu_graph.py │ │ └── window0_graph.py │ └── README.md ├── CPS-0022/ │ └── README.md ├── LICENSE └── README.md
SYMBOL INDEX (95 symbols across 16 files)
FILE: .github/scripts/validate-cps.py
function parse_frontmatter (line 54) | def parse_frontmatter(content: str) -> Tuple[Optional[Dict], Optional[st...
function extract_h2_headers (line 109) | def extract_h2_headers(content: str) -> List[str]:
function extract_h1_headers (line 120) | def extract_h1_headers(content: str) -> List[str]:
function validate_line_endings (line 131) | def validate_line_endings(file_path: Path) -> List[str]:
function validate_no_h1_headings (line 159) | def validate_no_h1_headings(content: str) -> List[str]:
function _validate_field_order (line 174) | def _validate_field_order(frontmatter: Dict) -> List[str]:
function validate_header (line 201) | def validate_header(frontmatter: Dict) -> List[str]:
function _validate_cip_label_entries (line 259) | def _validate_cip_label_entries(entries: list, field_name: str) -> List[...
function validate_sections (line 335) | def validate_sections(content: str) -> List[str]:
function is_cps_file (line 425) | def is_cps_file(file_path: Path) -> bool:
function validate_file (line 437) | def validate_file(file_path: Path) -> Tuple[bool, List[str]]:
function main (line 488) | def main():
FILE: CIP-0068/ref_impl/offchain.ts
type FilesDetails (line 26) | type FilesDetails = {
type Metadata (line 32) | type Metadata = {
function mintNFT (line 59) | async function mintNFT(
function burnNFT (line 87) | async function burnNFT(assetName: string): Promise<TxHash> {
function viewNFT (line 106) | async function viewNFT(assetName: string): Promise<Metadata> {
FILE: CIP-0071/example/voting.js
constant BURN_REDEEMER (line 13) | const BURN_REDEEMER = 'd87a80';
constant MAX_NFTS_TO_MINT (line 14) | const MAX_NFTS_TO_MINT = 20;
constant MAX_ATTEMPTS (line 15) | const MAX_ATTEMPTS = 12;
constant OPTIMIZE_HELIOS (line 16) | const OPTIMIZE_HELIOS = true;
constant SINGLE_NFT (line 17) | const SINGLE_NFT = 1n;
constant TEN_MINS (line 18) | const TEN_MINS = 600000;
constant TXN_WAIT_TIMEOUT (line 19) | const TXN_WAIT_TIMEOUT = 15000;
function getVoteCounterSourceCode (line 21) | function getVoteCounterSourceCode(pubKeyHash) {
function getBallotSourceCodeStr (line 33) | function getBallotSourceCodeStr(referencePolicyId, pollsClose, pubKeyHas...
function getCompiledCode (line 111) | function getCompiledCode(mintingSourceCode) {
function getLucidScript (line 115) | function getLucidScript(compiledCode) {
function getBallotSelection (line 122) | function getBallotSelection(ballotDomName) {
function waitForTxn (line 126) | async function waitForTxn(lucid, blockfrostKey, txHash) {
function mintBallot (line 143) | async function mintBallot(blockfrostKey, pubKeyHash, policyId, pollsClos...
function getVotingAssets (line 225) | async function getVotingAssets(votingPolicies, exclusions, lucid) {
function walletVotingAssets (line 253) | async function walletVotingAssets(blockfrostKey, votingPolicies, exclusi...
function votingAssetsAvailable (line 273) | async function votingAssetsAvailable(blockfrostKey, votingPolicies, excl...
function countBallots (line 284) | async function countBallots(blockfrostKey, pubKeyHash, policyId, pollsCl...
function redeemBallots (line 331) | async function redeemBallots(blockfrostKey, pubKeyHash, policyId, pollsC...
function burnBallots (line 391) | async function burnBallots(blockfrostKey, pubKeyHash, policyId, pollsClo...
FILE: CIP-0083/codesamples/democode-NODEJS.js
function calc_KeyIV (line 10) | function calc_KeyIV(passphrase, salt) { //passphrase as utf8 string, sal...
function encryptCardanoMessage (line 19) | function encryptCardanoMessage(decrypted_msg, passphrase = 'cardano') { ...
function decryptCardanoMessage (line 50) | function decryptCardanoMessage(encrypted_msg, passphrase = 'cardano') { ...
FILE: CIP-0083/codesamples/democode-PHP.php
function elapsedTime (line 9) | function elapsedTime($start) {
function getPbkdf2 (line 20) | function getPbkdf2($password, $salt, $iterations) {
function encryptCardanoMessage (line 24) | function encryptCardanoMessage($msg, $password = 'cardano', $iterations ...
function decryptCardanoMessage (line 45) | function decryptCardanoMessage($msg, $password = 'cardano', $iterations ...
FILE: CIP-0161/graph/scenario-cost-cross-thresholds.py
function ant_glance_praos (line 14) | def ant_glance_praos(rho): return 5e-10 * 2**(rho - 2)
function ant_patrol_praos (line 15) | def ant_patrol_praos(rho): return 5e-10 * 2**(rho - 1) + 2.16e-2 * 2**(r...
function owl_stare_praos (line 16) | def owl_stare_praos(rho): return 5e-10 * 2**(rho - 2) + 5e-2 * 2**(rho -...
function owl_survey_praos (line 17) | def owl_survey_praos(rho): return 5e-10 * 2**(rho - 2) + 7.16e-2 * 2**(r...
function phalanx_cost (line 20) | def phalanx_cost(rho, scale): return (scale * 2**(rho - 1)) / rho
function log_cost (line 23) | def log_cost(n_cpu): return np.log10(np.maximum(n_cpu * cost_per_cpu_hou...
function annotate_crossings (line 50) | def annotate_crossings(log_costs, color, threshold, position='above'):
FILE: CIP-0161/graph/scenario_cost_praos_vs_phalanx-full-scenarios.py
function ant_glance_praos (line 15) | def ant_glance_praos(rho): return 5e-10 * 2**(rho - 2)
function ant_patrol_praos (line 16) | def ant_patrol_praos(rho): return ant_glance_praos(rho) + 2.16e-2 * 2**(...
function owl_stare_praos (line 17) | def owl_stare_praos(rho): return ant_glance_praos(rho) + 5e-2 * 2**(rho ...
function owl_survey_praos (line 18) | def owl_survey_praos(rho): return ant_glance_praos(rho) + 7.16e-2 * 2**(...
function phalanx_curve (line 21) | def phalanx_curve(multiplier):
function compute_log_cost (line 29) | def compute_log_cost(n_cpu):
function draw_delta (line 85) | def draw_delta(rho_val, praos_label, phalanx_label, x_offset=3):
FILE: CIP-0161/graph/scenario_cost_praos_vs_phalanx.py
function ant_glance_praos (line 15) | def ant_glance_praos(rho):
function ant_glance_phalanx (line 18) | def ant_glance_phalanx(rho):
function ant_patrol_praos (line 21) | def ant_patrol_praos(rho):
function ant_patrol_phalanx (line 24) | def ant_patrol_phalanx(rho):
function owl_stare_praos (line 27) | def owl_stare_praos(rho):
function owl_stare_phalanx (line 30) | def owl_stare_phalanx(rho):
function owl_survey_praos (line 33) | def owl_survey_praos(rho):
function owl_survey_phalanx (line 36) | def owl_survey_phalanx(rho):
function compute_log_cost (line 40) | def compute_log_cost(n_cpu):
function draw_delta (line 84) | def draw_delta(rho_val, praos_label, phalanx_label, x_offset=3):
FILE: CIP-0161/graph/settlement-time-phalanx.py
function formatter (line 100) | def formatter(y, pos):
FILE: CIP-0161/graph/settlement-time-praos.py
function formatter (line 100) | def formatter(y, pos):
FILE: CIP-0161/graph/settlement-time-without-grinding.py
function formatter (line 100) | def formatter(y, pos):
FILE: CIP-0161/graph/vdf_benches.py
function bench_prove_and_verify (line 9) | def bench_prove_and_verify():
FILE: CPS-0021/CPD/graph/forking_probabilities.py
function proba_attempts (line 20) | def proba_attempts(w,x,s):
function number_attempts_adv (line 26) | def number_attempts_adv(w, x):
function number_attempts (line 34) | def number_attempts(w):
function expectation (line 44) | def expectation(w,x,s):
function eg (line 52) | def eg(s, precision=10, cores=2):
function all_egs (line 61) | def all_egs(precision=10, cores=1):
function proba_diff (line 71) | def proba_diff(diff, s, precision=10):
function tables (line 87) | def tables(precision=10, cores=1):
function parseArguments (line 107) | def parseArguments():
FILE: CPS-0021/CPD/graph/mixing_probabilities.py
function proba_attempts (line 19) | def proba_attempts(x,s):
function eg (line 22) | def eg(w,s):
function all_egs (line 29) | def all_egs(cores=1):
function tables (line 39) | def tables(cores=1):
function parseArguments (line 57) | def parseArguments():
FILE: CPS-0021/CPD/graph/scenario_cost-graph.py
function ant_glance_praos (line 17) | def ant_glance_praos(rho):
function ant_patrol_praos (line 20) | def ant_patrol_praos(rho):
function owl_stare_praos (line 23) | def owl_stare_praos(rho):
function owl_survey_praos (line 26) | def owl_survey_praos(rho):
function annotate_crossings (line 82) | def annotate_crossings(log_costs, color, threshold, position='above'):
FILE: CPS-0021/CPD/graph/scenario_cpu_graph.py
function ant_glance (line 8) | def ant_glance(rho):
function ant_patrol (line 11) | def ant_patrol(rho):
function owl_stare (line 14) | def owl_stare(rho):
function owl_survey (line 17) | def owl_survey(rho):
Condensed preview — 430 files, each showing path, character count, and a content snippet. Download the .json file or copy for the full structured content (5,554K chars).
[
{
"path": ".gitattributes",
"chars": 49,
"preview": "* linguist-vendored\n*.md linguist-vendored=false\n"
},
{
"path": ".github/CIP-TEMPLATE.md",
"chars": 3816,
"preview": "---\nCIP: ?\nTitle: ?\nCategory: ?\nStatus: Proposed\nAuthors:\n - John Doe <john.doe@email.domain>\nImplementors: []\nDiscus"
},
{
"path": ".github/CPS-TEMPLATE.md",
"chars": 3063,
"preview": "---\nCPS: ?\nTitle: ?\nCategory: ?\nStatus: Open\nAuthors:\n - John Doe <john.doe@email.domain>\nProposed Solutions: []\nDisc"
},
{
"path": ".github/CPS-VALIDATION.md",
"chars": 2996,
"preview": "# CPS Validation Rules\n\nThis document describes all validation rules applied to Cardano Problem Statement (CPS) document"
},
{
"path": ".github/schemas/cps-header.schema.json",
"chars": 4186,
"preview": "{\n \"$schema\": \"http://json-schema.org/draft-07/schema#\",\n \"$id\": \"https://github.com/cardano-foundation/CIPs/.github/s"
},
{
"path": ".github/scripts/validate-cps.py",
"chars": 19365,
"preview": "#!/usr/bin/env python3\n\"\"\"\nValidation script for CPS README.md files.\nValidates YAML headers and required sections.\n\"\"\"\n"
},
{
"path": ".github/workflows/cip10-validation.yaml",
"chars": 757,
"preview": "name: CIP-10 - Validate Registry JSON on Pull Request\n\non:\n pull_request:\n paths:\n - 'CIP-0010/registry.json'\n\n"
},
{
"path": ".github/workflows/cps-validation.yaml",
"chars": 2015,
"preview": "name: CPS Validation\n\non:\n pull_request:\n paths:\n - 'CPS*/README.md'\n - 'cps*/README.md'\n workflow_dispat"
},
{
"path": "BiweeklyMeetings/2020-07-01.md",
"chars": 4352,
"preview": "**Table of Contents:** \n\n- [Summary](#summary)\n- [Editors Meeting Flow](#editors-meeting-flow)\n- [July 1 2020 notes](#ju"
},
{
"path": "BiweeklyMeetings/2020-07-15.md",
"chars": 7257,
"preview": "**Table of Contents:** \n\n- [Summary](#summary)\n- [Editors Meeting Flow](#editors-meeting-flow)\n- [July 15 2020 notes](#j"
},
{
"path": "BiweeklyMeetings/2020-08-04.md",
"chars": 3962,
"preview": "**Table of Contents:** \n\n- [Summary](#summary)\n- [Editors Meeting Flow](#editors-meeting-flow)\n- [Aug 4 2020 notes](#aug"
},
{
"path": "BiweeklyMeetings/2020-08-11.md",
"chars": 6074,
"preview": " **Table of Contents:** \n\n- [Summary](#summary)\n- [Editors Meeting Flow](#editors-meeting-flow)\n- [August 11 2020 notes]"
},
{
"path": "BiweeklyMeetings/2020-08-25.md",
"chars": 4865,
"preview": " **Table of Contents:** \n\n- [Summary](#summary)\n- [Editors Meeting Flow](#editors-meeting-flow)\n- [August 25 2020 notes]"
},
{
"path": "BiweeklyMeetings/2020-09-08.md",
"chars": 3843,
"preview": " **Table of Contents:** \n\n- [Summary](#summary)\n- [Editors Meeting Flow](#editors-meeting-flow)\n- [September 08 2020 not"
},
{
"path": "BiweeklyMeetings/2020-09-22.md",
"chars": 9400,
"preview": " **Table of Contents:** \n\n- [Summary](#summary)\n- [Editors Meeting Flow](#editors-meeting-flow)\n- [September 22 2020 not"
},
{
"path": "BiweeklyMeetings/2020-10-06.md",
"chars": 6880,
"preview": " **Table of Contents:** \n\n- [Summary](#summary)\n- [Editors Meeting Flow](#editors-meeting-flow)\n- [October 06 2020 notes"
},
{
"path": "BiweeklyMeetings/2020-10-20.md",
"chars": 6857,
"preview": " **Table of Contents:** \n\n- [Summary](#summary)\n- [Editors Meeting Flow](#editors-meeting-flow)\n- [October 20 2020 notes"
},
{
"path": "BiweeklyMeetings/2020-11-03.md",
"chars": 12431,
"preview": " **Table of Contents:** \n\n- [Summary](#summary)\n- [Editors Meeting Flow](#editors-meeting-flow)\n- [November 3 2020 notes"
},
{
"path": "BiweeklyMeetings/2020-11-17.md",
"chars": 11190,
"preview": " **Table of Contents:** \n\n- [Summary](#summary)\n- [Editors Meeting Flow](#editors-meeting-flow)\n- [November 17 2020 note"
},
{
"path": "BiweeklyMeetings/2020-12-08.md",
"chars": 14591,
"preview": " **Table of Contents:** \n\n- [Summary](#summary)\n- [Editors Meeting Flow](#editors-meeting-flow)\n- [December 8 2020 notes"
},
{
"path": "BiweeklyMeetings/2021-01-12.md",
"chars": 15615,
"preview": " **Table of Contents:** \n\n- [Summary](#summary)\n- [Editors Meeting Flow](#editors-meeting-flow)\n- [January 12 2021 notes"
},
{
"path": "BiweeklyMeetings/2021-01-26.md",
"chars": 15179,
"preview": " **Table of Contents:** \n\n- [Summary](#summary)\n- [Editors Meeting Flow](#editors-meeting-flow)\n- [January 26 2021 notes"
},
{
"path": "BiweeklyMeetings/2021-02-09.md",
"chars": 15485,
"preview": " **Table of Contents:** \n\n- [Summary](#summary)\n- [Editors Meeting Flow](#editors-meeting-flow)\n- [February 9 2021 notes"
},
{
"path": "BiweeklyMeetings/2021-02-23.md",
"chars": 18231,
"preview": " **Table of Contents:** \n\n- [Summary](#summary)\n- [Editors Meeting Flow](#editors-meeting-flow)\n- [February 23 2021 note"
},
{
"path": "BiweeklyMeetings/2021-03-16.md",
"chars": 18368,
"preview": " **Table of Contents:** \n\n- [Summary](#summary)\n- [Editors Meeting Flow](#editors-meeting-flow)\n- [March 16 2021 notes]("
},
{
"path": "BiweeklyMeetings/2021-03-30.md",
"chars": 15332,
"preview": " **Table of Contents:** \n\n- [Summary](#summary)\n- [Editors Meeting Flow](#editors-meeting-flow)\n- [March 30 2021 notes]("
},
{
"path": "BiweeklyMeetings/2021-04-13.md",
"chars": 20117,
"preview": " **Table of Contents:** \n\n- [Summary](#summary)\n- [Editors Meeting Flow](#editors-meeting-flow)\n- [April 13 2021 notes]("
},
{
"path": "BiweeklyMeetings/2021-04-27.md",
"chars": 19628,
"preview": " **Table of Contents:** \n\n- [Summary](#summary)\n- [Editors Meeting Flow](#editors-meeting-flow)\n- [April 27 2021 notes]("
},
{
"path": "BiweeklyMeetings/2021-05-11.md",
"chars": 23781,
"preview": " **Table of Contents:** \n\n- [Summary](#summary)\n- [Editors Meeting Flow](#editors-meeting-flow)\n- [May 11 2021 notes](#m"
},
{
"path": "BiweeklyMeetings/2021-05-25.md",
"chars": 20556,
"preview": " **Table of Contents:** \n\n- [Summary](#summary)\n- [Editors Meeting Flow](#editors-meeting-flow)\n- [May 25 2021 notes](#m"
},
{
"path": "BiweeklyMeetings/2021-06-08.md",
"chars": 20016,
"preview": " **Table of Contents:** \n\n- [Summary](#summary)\n- [Editors Meeting Flow](#editors-meeting-flow)\n- [June 8 2021 notes](#j"
},
{
"path": "BiweeklyMeetings/2021-06-29.md",
"chars": 28382,
"preview": " **Table of Contents:** \n\n- [Summary](#summary)\n- [Editors Meeting Flow](#editors-meeting-flow)\n- [June 29 2021 notes](#"
},
{
"path": "BiweeklyMeetings/2021-07-20.md",
"chars": 29454,
"preview": " **Table of Contents:** \n\n- [Summary](#summary)\n- [Editors Meeting Flow](#editors-meeting-flow)\n- [July 20 2021 notes](#"
},
{
"path": "BiweeklyMeetings/2021-08-03.md",
"chars": 30179,
"preview": " **Table of Contents:** \n\n- [Summary](#summary)\n- [Editors Meeting Flow](#editors-meeting-flow)\n- [August 3 2021 notes]("
},
{
"path": "BiweeklyMeetings/2021-08-17.md",
"chars": 18116,
"preview": " **Table of Contents:** \n\n- [Summary](#summary)\n- [Editors Meeting Flow](#editors-meeting-flow)\n- [August 17 2021 notes]"
},
{
"path": "BiweeklyMeetings/2021-09-07.md",
"chars": 12922,
"preview": " **Table of Contents:** \n\n- [Summary](#summary)\n- [Editors Meeting Flow](#editors-meeting-flow)\n- [September 7 2021 note"
},
{
"path": "BiweeklyMeetings/2021-09-21.md",
"chars": 16525,
"preview": " **Table of Contents:** \n\n- [Summary](#summary)\n- [Editors Meeting Flow](#editors-meeting-flow)\n- [September 21 2021 not"
},
{
"path": "BiweeklyMeetings/2021-10-05.md",
"chars": 22838,
"preview": " **Table of Contents:** \n\n- [Summary](#summary)\n- [Editors Meeting Flow](#editors-meeting-flow)\n- [October 5 2021 notes]"
},
{
"path": "BiweeklyMeetings/2021-10-19.md",
"chars": 22290,
"preview": " **Table of Contents:** \n\n- [Summary](#summary)\n- [Editors Meeting Flow](#editors-meeting-flow)\n- [October 19 2021 notes"
},
{
"path": "BiweeklyMeetings/2021-11-09.md",
"chars": 26345,
"preview": " **Table of Contents:** \n\n- [Summary](#summary)\n- [Editors Meeting Flow](#editors-meeting-flow)\n- [November 9 2021 notes"
},
{
"path": "BiweeklyMeetings/2021-11-23.md",
"chars": 21419,
"preview": " **Table of Contents:** \n\n- [Summary](#summary)\n- [Editors Meeting Flow](#editors-meeting-flow)\n- [November 23 2021 note"
},
{
"path": "BiweeklyMeetings/2021-12-07.md",
"chars": 24325,
"preview": " **Table of Contents:** \n\n- [Summary](#summary)\n- [Editors Meeting Flow](#editors-meeting-flow)\n- [December 7 2021 notes"
},
{
"path": "BiweeklyMeetings/2021-12-21.md",
"chars": 21265,
"preview": " **Table of Contents:** \n\n- [Summary](#summary)\n- [Editors Meeting Flow](#editors-meeting-flow)\n- [December 21 2021 note"
},
{
"path": "BiweeklyMeetings/2022-01-11.md",
"chars": 26146,
"preview": " **Table of Contents:** \n\n- [Summary](#summary)\n- [Editors Meeting Flow](#editors-meeting-flow)\n- [January 11 2022 notes"
},
{
"path": "BiweeklyMeetings/2022-01-25.md",
"chars": 32165,
"preview": " **Table of Contents:** \n\n- [Summary](#summary)\n- [Editors Meeting Flow](#editors-meeting-flow)\n- [January 25 2022 notes"
},
{
"path": "BiweeklyMeetings/2022-02-15.md",
"chars": 45664,
"preview": "**Table of Contents:** \n\n- [Summary](#summary)\n- [Editors Meeting Flow](#editors-meeting-flow)\n- [February 15 2022 notes"
},
{
"path": "BiweeklyMeetings/2022-03-01.md",
"chars": 48069,
"preview": "**Table of Contents:** \n\n- [Summary](#summary)\n- [Editors Meeting Flow](#editors-meeting-flow)\n- [March 1 2022 Transcrip"
},
{
"path": "BiweeklyMeetings/2022-03-15.md",
"chars": 51909,
"preview": "**Table of Contents:** \n\n- [Summary](#summary)\n- [Editors Meeting Flow](#editors-meeting-flow)\n- [March 15 2022 Transcri"
},
{
"path": "BiweeklyMeetings/2022-04-05.md",
"chars": 44470,
"preview": "**Table of Contents:** \n\n- [Summary](#summary)\n\n- [Editors Meeting Flow](#editors-meeting-flow)\n\n- [April 05 2022 Transc"
},
{
"path": "BiweeklyMeetings/2022-04-12.md",
"chars": 42160,
"preview": "**Table of Contents:** \n\n- [Summary](#summary)\n- [Editors Meeting Flow](#editors-meeting-flow)\n- [April 12 2022 Transcri"
},
{
"path": "BiweeklyMeetings/2022-05-10.md",
"chars": 38791,
"preview": "**Table of Contents:** \n\n- [Summary](#summary)\n- [Editors Meeting Flow](#editors-meeting-flow)\n- [May 10 2022 Transcript"
},
{
"path": "BiweeklyMeetings/2022-05-24.md",
"chars": 51218,
"preview": "**Table of Contents:** \n\n- [Summary](#summary)\n- [Editors Meeting Flow](#editors-meeting-flow)\n- [May 24 2022 Transcript"
},
{
"path": "BiweeklyMeetings/2022-06-07.md",
"chars": 34646,
"preview": "**Table of Contents:** \n\n- [Summary](#summary)\n- [Editors Meeting Flow](#editors-meeting-flow)\n- [June 07 2022 Transcrip"
},
{
"path": "BiweeklyMeetings/2022-06-28.md",
"chars": 38560,
"preview": "**Table of Contents:** \n\n- [Summary](#summary)\n- [Editors Meeting Flow](#editors-meeting-flow)\n- [June 28 2022 Transcrip"
},
{
"path": "BiweeklyMeetings/2022-07-05.md",
"chars": 30004,
"preview": "**Table of Contents:** \n\n- [Summary](#summary)\n- [Editors Meeting Flow](#editors-meeting-flow)\n- [July 05 2022 Transcrip"
},
{
"path": "BiweeklyMeetings/2022-07-19.md",
"chars": 34628,
"preview": "**Table of Contents:** \n\n- [Summary](#summary)\n- [Editors Meeting Flow](#editors-meeting-flow)\n- [July 19 2022 Transcrip"
},
{
"path": "BiweeklyMeetings/2022-08-02.md",
"chars": 33575,
"preview": "**Table of Contents:** \n\n- [Summary](#summary)\n- [Editors Meeting Flow](#editors-meeting-flow)\n- [August 02 2022 Transcr"
},
{
"path": "BiweeklyMeetings/2022-08-16.md",
"chars": 42338,
"preview": "**Table of Contents:** \n\n- [Summary](#summary)\n- [Editors Meeting Flow](#editors-meeting-flow)\n- [August 16 2022 Transcr"
},
{
"path": "BiweeklyMeetings/2022-09-06.md",
"chars": 42148,
"preview": "**Table of Contents:** \n\n- [Summary](#summary)\n- [Editors Meeting Flow](#editors-meeting-flow)\n- [September 06 2022 Tran"
},
{
"path": "CIP-0001/CIP-0001.md",
"chars": 44,
"preview": "Moved to [CIP-0001/README.md](./README.md).\n"
},
{
"path": "CIP-0001/README.md",
"chars": 39131,
"preview": "---\nCIP: 1\nTitle: CIP Process\nCategory: Meta\nStatus: Active\nAuthors:\n - Frederic Johnson <frederic@advanceweb3.com>\n "
},
{
"path": "CIP-0002/CIP-0002.md",
"chars": 44,
"preview": "Moved to [CIP-0002/README.md](./README.md).\n"
},
{
"path": "CIP-0002/README.md",
"chars": 41341,
"preview": "---\nCIP: 2\nTitle: Coin Selection Algorithms for Cardano\nCategory: Wallets\nAuthors:\n - Jonathan Knowles <jonathan.know"
},
{
"path": "CIP-0003/Byron.md",
"chars": 1571,
"preview": "# Byron key format\n\n- **Deprecated**: yes\n- **Summary**: used by old versions of Daedalus to generate addresses starting"
},
{
"path": "CIP-0003/CIP-0003.md",
"chars": 44,
"preview": "Moved to [CIP-0003/README.md](./README.md).\n"
},
{
"path": "CIP-0003/Icarus.md",
"chars": 2794,
"preview": "# Icarus key format\n\n- **Deprecated**: no\n- **Summary**: Used by Yoroi during the Byron-era (with Byron-style addresses "
},
{
"path": "CIP-0003/Ledger_BitBox02.md",
"chars": 3095,
"preview": "# Ledger/BitBox02 key format\n\n- **Deprecated**: no\n- **Summary**: Used by Ledger hardware wallets\n\nReference implementat"
},
{
"path": "CIP-0003/README.md",
"chars": 4439,
"preview": "---\nCIP: 3\nTitle: Wallet Key Generation\nStatus: Active\nCategory: Wallets\nAuthors:\n - Matthias Benkort <matthias.benko"
},
{
"path": "CIP-0004/CIP-0004.md",
"chars": 44,
"preview": "Moved to [CIP-0004/README.md](./README.md).\n"
},
{
"path": "CIP-0004/README.md",
"chars": 8345,
"preview": "---\nCIP: 4\nTitle: Wallet Checksums\nStatus: Proposed\nCategory: Wallets\nAuthors:\n - Ruslan Dudin <ruslan@emurgo.io>\n - S"
},
{
"path": "CIP-0005/CIP-0005.md",
"chars": 44,
"preview": "Moved to [CIP-0005/README.md](./README.md).\n"
},
{
"path": "CIP-0005/README.md",
"chars": 21195,
"preview": "---\nCIP: 5\nTitle: Common Bech32 Prefixes\nCategory: Tools\nStatus: Active\nAuthors:\n - Matthias Benkort <matthias.benkort@"
},
{
"path": "CIP-0006/CIP-0006.md",
"chars": 44,
"preview": "Moved to [CIP-0006/README.md](./README.md).\n"
},
{
"path": "CIP-0006/README.md",
"chars": 7171,
"preview": "---\nCIP: 6\nTitle: Stake Pool Extended Metadata\nStatus: Active\nCategory: Tools\nAuthors:\n - Markus Gufler <gufmar@gmail.c"
},
{
"path": "CIP-0006/schema.json",
"chars": 9192,
"preview": "{\n \"$id\": \"https://raw.githubusercontent.com/cardano-foundation/CIPs/master/CIP-0006/schema.json\",\n \"$schema\": \"http:/"
},
{
"path": "CIP-0007/CIP-0007.md",
"chars": 44,
"preview": "Moved to [CIP-0007/README.md](./README.md).\n"
},
{
"path": "CIP-0007/README.md",
"chars": 5939,
"preview": "---\nCIP: 7\nTitle: Curve Pledge Benefit\nAuthors:\n - Shawn McMurdo <shawn_mcmurdo@yahoo.com>\nCategory: Ledger\nStatus: Pro"
},
{
"path": "CIP-0007/rewards.php",
"chars": 3431,
"preview": "<?php\n\n$argc = count($argv);\n\nif ($argc == 1) {\n // The n-root curve exponent. 1 = linear, 2 = square root, 3 = cube ro"
},
{
"path": "CIP-0008/CIP-0008.md",
"chars": 44,
"preview": "Moved to [CIP-0008/README.md](./README.md).\n"
},
{
"path": "CIP-0008/README.md",
"chars": 19524,
"preview": "---\nCIP: 8\nTitle: Message Signing\nStatus: Active\nCategory: Tools\nAuthors:\n - Sebastien Guillemot <sebastien@emurgo.io>\n"
},
{
"path": "CIP-0009/CIP-0009.md",
"chars": 44,
"preview": "Moved to [CIP-0009/README.md](./README.md).\n"
},
{
"path": "CIP-0009/README.md",
"chars": 21640,
"preview": "---\nCIP: 9\nTitle: Protocol Parameters (Shelley Era)\nStatus: Active\nCategory: Ledger\nAuthors:\n - Kevin Hammond <kevin.ha"
},
{
"path": "CIP-0010/CIP-0010.md",
"chars": 44,
"preview": "Moved to [CIP-0010/README.md](./README.md).\n"
},
{
"path": "CIP-0010/README.md",
"chars": 3458,
"preview": "---\nCIP: 10\nTitle: Transaction Metadata Label Registry\nStatus: Active\nCategory: Metadata\nAuthors:\n - Sebastien Guillemo"
},
{
"path": "CIP-0010/registry.json",
"chars": 5163,
"preview": "[\n {\n \"transaction_metadatum_label\": 22,\n \"description\": \"Clarity - DAO creation metadata\"\n },\n {\n \"transact"
},
{
"path": "CIP-0010/registry.schema.json",
"chars": 692,
"preview": "{\n \"$schema\": \"http://json-schema.org/draft-07/schema#\",\n \"$id\": \"https://github.com/cardano-foundation/CIPs/blob/"
},
{
"path": "CIP-0011/CIP-0011.md",
"chars": 44,
"preview": "Moved to [CIP-0011/README.md](./README.md).\n"
},
{
"path": "CIP-0011/README.md",
"chars": 3998,
"preview": "---\nCIP: 11\nTitle: Staking key chain for HD wallets\nStatus: Active\nCategory: Wallets\nAuthors:\n - Sebastien Guillemot <s"
},
{
"path": "CIP-0012/CIP-0012.md",
"chars": 44,
"preview": "Moved to [CIP-0012/README.md](./README.md).\n"
},
{
"path": "CIP-0012/README.md",
"chars": 6154,
"preview": "---\nCIP: 12\nTitle: On-chain stake pool operator to delegates communication\nStatus: Proposed\nCategory: Metadata\nAuthors:\n"
},
{
"path": "CIP-0012/schema.json",
"chars": 2833,
"preview": "{\n \"$schema\": \"http://json-schema.org/draft-07/schema\",\n \"$id\": \"https://github.com/cardano-foundation/CIPs/blob/maste"
},
{
"path": "CIP-0013/CIP-0013.md",
"chars": 44,
"preview": "Moved to [CIP-0013/README.md](./README.md).\n"
},
{
"path": "CIP-0013/README.md",
"chars": 12862,
"preview": "---\nCIP: 13\nTitle: Cardano URI Scheme\nStatus: Proposed\nCategory: Wallets\nAuthors:\n - Robert Phair <rphair@cosd.com>\n "
},
{
"path": "CIP-0014/CIP-0014.md",
"chars": 44,
"preview": "Moved to [CIP-0014/README.md](./README.md).\n"
},
{
"path": "CIP-0014/README.md",
"chars": 6865,
"preview": "---\nCIP: 14\nTitle: User-Facing Asset Fingerprint \nStatus: Active\nCategory: Tokens\nAuthors:\n - Matthias Benkort <matthia"
},
{
"path": "CIP-0015/CIP-0015.md",
"chars": 44,
"preview": "Moved to [CIP-0015/README.md](./README.md).\n"
},
{
"path": "CIP-0015/README.md",
"chars": 7132,
"preview": "---\nCIP: 15\nTitle: Registration Transaction Metadata Format\nCategory: Metadata\nStatus: Active\nAuthors:\n - Sebastien G"
},
{
"path": "CIP-0015/schema.cddl",
"chars": 393,
"preview": "registration_cbor = {\n 61284: key_registration,\n 61285: registration_signature\n}\n\n$voting_pub_key /= bytes .size 32\n$s"
},
{
"path": "CIP-0015/test-vector.md",
"chars": 1726,
"preview": "# Test vector for CIP15\n\n### Inputs\n\nPayment **public** key hex\n```\n3273a5316e4de228863bd7cf8dac90d57149e1a595f3dd131073"
},
{
"path": "CIP-0016/CIP-0016.md",
"chars": 44,
"preview": "Moved to [CIP-0016/README.md](./README.md).\n"
},
{
"path": "CIP-0016/README.md",
"chars": 5106,
"preview": "---\nCIP: 16\nTitle: Cryptographic Key Serialisation Formats\nStatus: Active\nCategory: Tools\nAuthors:\n - Luke Nadur <luke."
},
{
"path": "CIP-0017/CIP-0017.json",
"chars": 1337,
"preview": "{ \"title\": \"CIP-0017 - Cardano Delegation Portfolio\"\n, \"$schema\": \"https://json-schema.org/draft-07/schema\"\n, \"type\": \"o"
},
{
"path": "CIP-0017/CIP-0017.md",
"chars": 44,
"preview": "Moved to [CIP-0017/README.md](./README.md).\n"
},
{
"path": "CIP-0017/README.md",
"chars": 5000,
"preview": "---\nCIP: 17\nTitle: Cardano Delegation Portfolio\nStatus: Inactive (abandoned for lack of interest)\nCategory: Tools\nAuthor"
},
{
"path": "CIP-0018/CIP-0018.md",
"chars": 44,
"preview": "Moved to [CIP-0018/README.md](./README.md).\n"
},
{
"path": "CIP-0018/README.md",
"chars": 9536,
"preview": "---\nCIP: 18\nTitle: Multi-Stake-Keys Wallets \nStatus: Proposed\nCategory: Wallets\nAuthors:\n - Matthias Benkort <matthias."
},
{
"path": "CIP-0019/CIP-0019-byron-addresses.cddl",
"chars": 1049,
"preview": "BYRON_ADDRESS =\n ( #6.24(<<BYRON_ADDRESS_PAYLOAD>>)\n , uint32 ; crc32 of the CBOR serialized address payload\n )"
},
{
"path": "CIP-0019/CIP-0019-cardano-addresses.abnf",
"chars": 1540,
"preview": "ADDRESS = %b0000 | NETWORK-TAG | KEY-HASH | KEY-HASH ; type 00, Base Shelley address\n \\ %b0001 | NETWORK"
},
{
"path": "CIP-0019/CIP-0019.md",
"chars": 44,
"preview": "Moved to [CIP-0019/README.md](./README.md).\n"
},
{
"path": "CIP-0019/README.md",
"chars": 16943,
"preview": "---\nCIP: 19\nTitle: Cardano Addresses\nStatus: Active\nCategory: Ledger\nAuthors:\n - Matthias Benkort <matthias.benkort@car"
},
{
"path": "CIP-0020/CIP-0020.md",
"chars": 44,
"preview": "Moved to [CIP-0020/README.md](./README.md).\n"
},
{
"path": "CIP-0020/README.md",
"chars": 9895,
"preview": "---\nCIP: 20\nTitle: Transaction message/comment metadata\nStatus: Active\nCategory: Metadata\nAuthors:\n - Martin Lang <ma"
},
{
"path": "CIP-0021/CIP-0021.md",
"chars": 44,
"preview": "Moved to [CIP-0021/README.md](./README.md).\n"
},
{
"path": "CIP-0021/README.md",
"chars": 13657,
"preview": "---\nCIP: 21\nTitle: Transaction requirements for interoperability with hardware wallets\nStatus: Active\nCategory: Wallets\n"
},
{
"path": "CIP-0022/CIP-0022.md",
"chars": 44,
"preview": "Moved to [CIP-0022/README.md](./README.md).\n"
},
{
"path": "CIP-0022/README.md",
"chars": 8145,
"preview": "---\nCIP: 22\nTitle: Pool operator verification\nStatus: Active\nCategory: Tools\nAuthors:\n - Andrew Westberg <andrewwestber"
},
{
"path": "CIP-0023/CIP-0023.md",
"chars": 44,
"preview": "Moved to [CIP-0023/README.md](./README.md).\n"
},
{
"path": "CIP-0023/README.md",
"chars": 11926,
"preview": "---\nCIP: 23\nTitle: Fair Min Fees\nAuthors:\n - Shawn McMurdo <shawn_mcmurdo@yahoo.com>\n - Ryan Wiley <rian222@gmail.com>"
},
{
"path": "CIP-0023/minfees.php",
"chars": 3962,
"preview": "<?php\n\n$argc = count($argv);\n\nif ($argc == 3) {\n $new_fixed = $argv[1];\n $new_rate = $argv[2];\n $pledge = 100000;\n} e"
},
{
"path": "CIP-0024/CIP-0024.md",
"chars": 44,
"preview": "Moved to [CIP-0024/README.md](./README.md).\n"
},
{
"path": "CIP-0024/README.md",
"chars": 5009,
"preview": "---\nCIP: 24\nTitle: Non-Centralizing Rankings\nAuthors:\n - Shawn McMurdo <shawn_mcmurdo@yahoo.com>\nCategory: Wallets\nStat"
},
{
"path": "CIP-0025/CIP-0025.md",
"chars": 44,
"preview": "Moved to [CIP-0025/README.md](./README.md).\n"
},
{
"path": "CIP-0025/README.md",
"chars": 8816,
"preview": "---\nCIP: 25\nTitle: Media Token Metadata Standard\nStatus: Active\nCategory: Tokens\nAuthors:\n - Alessandro Konrad <alessan"
},
{
"path": "CIP-0025/cddl/version_1.cddl",
"chars": 474,
"preview": "string = text .size (0..64)\n\npolicy_id = string\nasset_name = string ; utf-8\n\nfiles_details = \n {\n name : string,\n "
},
{
"path": "CIP-0025/cddl/version_2.cddl",
"chars": 538,
"preview": "string = text .size (0..64)\n\npolicy_id = bytes ; no longer in text\nasset_name = bytes ; no longer in text and utf-8\n\nfil"
},
{
"path": "CIP-0026/README.md",
"chars": 30472,
"preview": "---\nCIP: 26\nTitle: Cardano Off-Chain Metadata\nStatus: Active\nCategory: Metadata\nAuthors:\n - Matthias Benkort <matthias."
},
{
"path": "CIP-0026/schema.json",
"chars": 3623,
"preview": "{ \"title\": \"Cardano Off-Chain Metadata\"\n, \"$schema\": \"https://json-schema.org/draft-07/schema\"\n, \"required\":\n [ \"subjec"
},
{
"path": "CIP-0027/CIP-0027.md",
"chars": 44,
"preview": "Moved to [CIP-0027/README.md](./README.md).\n"
},
{
"path": "CIP-0027/README.md",
"chars": 5019,
"preview": "---\nCIP: 27\nTitle: CNFT Community Royalties Standard\nStatus: Active\nCategory: Tokens\nAuthors:\n - Huth S0lo <john@digita"
},
{
"path": "CIP-0028/README.md",
"chars": 14910,
"preview": "---\nCIP: 28\nTitle: Protocol Parameters (Alonzo Era)\nStatus: Active\nCategory: Ledger\nAuthors:\n - Kevin Hammond <kevin.ha"
},
{
"path": "CIP-0029/CIP-0029.md",
"chars": 44,
"preview": "Moved to [CIP-0029/README.md](./README.md).\n"
},
{
"path": "CIP-0029/README.md",
"chars": 4257,
"preview": "---\nCIP: 29\nTitle: Phase-1 Monetary Scripts Serialization Formats\nStatus: Active\nCategory: Tools\nAuthors:\n - Matthias B"
},
{
"path": "CIP-0029/phase-1-monetary-scripts.cddl",
"chars": 580,
"preview": "script =\n [ script_key\n // script_all\n // script_any\n // script_n_of_k\n // script_after\n // script_before\n ]\n\nsc"
},
{
"path": "CIP-0029/phase-1-monetary-scripts.json",
"chars": 3040,
"preview": "{ \"$schema\": \"<https://json-schema.org/draft-07/schema>\"\n, \"title\": \"Phase-1 Monetary Scripts\"\n, \"oneOf\":\n [ { \"$ref\""
},
{
"path": "CIP-0030/README.md",
"chars": 28339,
"preview": "---\nCIP: 30\nTitle: Cardano dApp-Wallet Web Bridge\nStatus: Active\nCategory: Wallets\nAuthors:\n - rooooooooob\nImplementors"
},
{
"path": "CIP-0030/extensions-register.md",
"chars": 1082,
"preview": "# CIP-30 Accepted Extensions Register\n\nThis registry aims to document all CIP-30 extensions accepted as CIPs.\n\nThe aim o"
},
{
"path": "CIP-0031/README.md",
"chars": 16454,
"preview": "---\nCIP: 31\nTitle: Reference inputs\nStatus: Active\nCategory: Plutus\nAuthors:\n - Michael Peyton Jones <michael.peyton-"
},
{
"path": "CIP-0032/README.md",
"chars": 10478,
"preview": "---\nCIP: 32\nTitle: Inline datums\nStatus: Active\nCategory: Plutus\nAuthors:\n - Michael Peyton Jones <michael.peyton-jon"
},
{
"path": "CIP-0033/README.md",
"chars": 7537,
"preview": "---\nCIP: 33\nTitle: Reference scripts\nStatus: Active\nCategory: Plutus\nAuthors:\n - Michael Peyton Jones <michael.peyton"
},
{
"path": "CIP-0034/README.md",
"chars": 3004,
"preview": "---\nCIP: 34\nTitle: Chain ID Registry\nStatus: Proposed\nCategory: Tools\nAuthors:\n - Sebastien Guillemot <seba@dcspark.io>"
},
{
"path": "CIP-0034/registry.json",
"chars": 814,
"preview": "{\n \"PreProduction\": {\n \"Name\": \"Pre-Production\",\n \"NetworkId\": 0,\n \"NetworkMagic\": 1,\n \"G"
},
{
"path": "CIP-0034/schema.json",
"chars": 799,
"preview": "{\n \"definitions\": {\n \"network\": {\n \"$id\": \"#/definitions/network\",\n \"type\": \"object\",\n \"properties\": "
},
{
"path": "CIP-0035/README.md",
"chars": 23728,
"preview": "---\nCIP: 35\nTitle: Changes to Plutus Core\nStatus: Active\nCategory: Meta\nAuthors:\n - Michael Peyton Jones <michael.peyto"
},
{
"path": "CIP-0036/README.md",
"chars": 17490,
"preview": "---\nCIP: 36\nTitle: Catalyst Registration Transaction Metadata Format (Updated)\nCategory: Tools\nStatus: Proposed\nAuthors:"
},
{
"path": "CIP-0036/schema.cddl",
"chars": 1307,
"preview": "registration_cbor = {\n 61284: key_registration,\n 61285: registration_witness\n}\n\n$cip36_vote_pub_key /= bytes .size 32\n"
},
{
"path": "CIP-0036/test-vector.md",
"chars": 3976,
"preview": "# Test Vector for CIP-0036\n\n## Keys\n\n**Note:** Not all keys are required for certificate recreation.\n\nPayment **private*"
},
{
"path": "CIP-0037/README.md",
"chars": 10606,
"preview": "---\nCIP: 37 \nTitle: Dynamic Saturation Based on Pledge\nStatus: Proposed\nCategory: Ledger\nAuthors:\n - Casey Gibson <case"
},
{
"path": "CIP-0040/README.md",
"chars": 4215,
"preview": "---\nCIP: 40\nTitle: Collateral Output\nStatus: Active\nCategory: Ledger\nAuthors:\n - Sebastien Guillemot <seba@dcspark.io>\n"
},
{
"path": "CIP-0042/README.md",
"chars": 9249,
"preview": "---\nCIP: 42\nTitle: New Plutus Builtin serialiseData\nStatus: Active\nCategory: Plutus\nAuthors:\n - Matthias Benkort <matth"
},
{
"path": "CIP-0045/README.md",
"chars": 13947,
"preview": "---\nCIP: 45\nTitle: Decentralized WebRTC dApp-Wallet Communication\nStatus: Active\nCategory: Wallets\nAuthors: \n - Fabia"
},
{
"path": "CIP-0049/README.md",
"chars": 9938,
"preview": "---\nCIP: 49\nTitle: ECDSA and Schnorr signatures in Plutus Core\nStatus: Active\nCategory: Plutus\nAuthors:\n - Koz Ross <ko"
},
{
"path": "CIP-0050/README.md",
"chars": 30693,
"preview": "---\nCIP: 50\nTitle: Pledge Leverage-Based Staking Rewards\nCategory: Ledger\nStatus: Proposed\nAuthors:\n - Michael Liesenfe"
},
{
"path": "CIP-0052/README.md",
"chars": 21378,
"preview": "---\nCIP: 52\nTitle: Cardano audit best practice guidelines\nStatus: Proposed\nCategory: Meta\nAuthors:\n - Simon Thompson <s"
},
{
"path": "CIP-0052/Tx-spec.md",
"chars": 3390,
"preview": "# Cardano Tx blueprint specification\n\n## Purpose\nEstablish a standard submitter requirement for a Plutus on-chain audit."
},
{
"path": "CIP-0054/README.md",
"chars": 16709,
"preview": "---\nCIP: 54\nTitle: Cardano Smart NFTs\nStatus: Proposed\nCategory: Tokens\nAuthors:\n - Kieran Simkin <hi@clg.wtf>\nImplemen"
},
{
"path": "CIP-0055/README.md",
"chars": 4990,
"preview": "---\nCIP: 55\nTitle: Protocol Parameters (Babbage Era)\nStatus: Active\nCategory: Ledger\nAuthors:\n - Jared Corduan <jared.c"
},
{
"path": "CIP-0057/README.md",
"chars": 27626,
"preview": "---\nCIP: 57\nTitle: Plutus Contract Blueprint\nStatus: Active\nCategory: Tools\nAuthors:\n - KtorZ <matthias.benkort@cardano"
},
{
"path": "CIP-0057/schemas/README.md",
"chars": 1138,
"preview": "# Plutus Contract Blueprint - Meta-Schemas\n\nIn these folders you'll find meta JSON-schemas for CIP-0057; Meta-schemas ar"
},
{
"path": "CIP-0057/schemas/plutus-blueprint-argument.json",
"chars": 2025,
"preview": "{\n \"$schema\": \"https://json-schema.org/draft/2020-12/schema\",\n \"$id\": \"https://cips.cardano.org/cips/cip57/schemas"
},
{
"path": "CIP-0057/schemas/plutus-blueprint-parameter.json",
"chars": 2113,
"preview": "{\n \"$schema\": \"https://json-schema.org/draft/2020-12/schema\",\n \"$id\": \"https://cips.cardano.org/cips/cip57/schemas"
},
{
"path": "CIP-0057/schemas/plutus-blueprint.json",
"chars": 3589,
"preview": "{\n \"$schema\": \"https://json-schema.org/draft/2020-12/schema\",\n \"$id\": \"https://cips.cardano.org/cips/cip57/schemas"
},
{
"path": "CIP-0057/schemas/plutus-builtin.json",
"chars": 4836,
"preview": "{\n \"$schema\": \"https://json-schema.org/draft/2020-12/schema\",\n \"$id\": \"https://cips.cardano.org/cips/cip57/schemas"
},
{
"path": "CIP-0057/schemas/plutus-data.json",
"chars": 4636,
"preview": "{\n \"$schema\": \"https://json-schema.org/draft/2020-12/schema\",\n \"$id\": \"https://cips.cardano.org/cips/cip57/schemas"
},
{
"path": "CIP-0058/README.md",
"chars": 37449,
"preview": "---\nCIP: 58\nTitle: Plutus Bitwise Primitives\nCategory: Plutus\nAuthors:\n - Koz Ross <koz@mlabs.city>\n - Maximilian "
},
{
"path": "CIP-0059/README.md",
"chars": 7349,
"preview": "---\nCIP: 59\nTitle: Terminology Surrounding Core Features\nStatus: Active\nCategory: Meta\nAuthors:\n - Jared Corduan <jared"
},
{
"path": "CIP-0059/feature-table.md",
"chars": 1918,
"preview": "# Cardano Features\n\n| Date | Phase | Era | Slot Number | Epoch Number | Protocol Version | Ledger Protocol | C"
},
{
"path": "CIP-0060/README.md",
"chars": 46700,
"preview": "---\nCIP: 60\nTitle: Music Token Metadata\nStatus: Active\nCategory: Metadata\nAuthors:\n - Andrew Westberg <awestberg@projec"
},
{
"path": "CIP-0060/cddl/version-1.cddl",
"chars": 4060,
"preview": "string = text .size (0..64)\n\npolicy_id = string / bytes ; hex string for CIP-25 version 1, bytes version 2\nasset_name = "
},
{
"path": "CIP-0060/cddl/version-2.cddl",
"chars": 3437,
"preview": "string = text .size (0..64)\n\npolicy_id = string / bytes ; hex string for CIP-25 version 1, bytes version 2\nasset_name = "
},
{
"path": "CIP-0060/cddl/version-3.cddl",
"chars": 2530,
"preview": "string = text .size (0..64)\npolicy_id = string / bytes ; hex string for CIP-25 version 1, bytes version 2\nasset_name = s"
},
{
"path": "CIP-0067/README.md",
"chars": 7665,
"preview": "---\nCIP: 67\nTitle: Asset Name Label Registry\nStatus: Proposed\nCategory: Tokens\nAuthors: \n - Alessandro Konrad <alessand"
},
{
"path": "CIP-0067/registry.json",
"chars": 1103,
"preview": "[\n {\n \"asset_name_label\": 100,\n \"class\": \"NFT\",\n \"description\": \"CIP-0068 - Datum Metadata Standard (Reference"
},
{
"path": "CIP-0067/registry.schema.json",
"chars": 2282,
"preview": "{\n \"$schema\": \"http://json-schema.org/draft-07/schema\",\n \"$id\": \"https://cips.cardano.org/cips/cip67/registry.schema.j"
},
{
"path": "CIP-0068/README.md",
"chars": 25316,
"preview": "---\nCIP: 68\nTitle: Datum Metadata Standard\nStatus: Active\nCategory: Tokens\nAuthors:\n - Alessandro Konrad <alessandro.ko"
},
{
"path": "CIP-0068/extension_boilerplate.md",
"chars": 2548,
"preview": "### Extending & Modifying this CIP\n\n> The keywords \"MUST\", \"MUST NOT\", \"REQUIRED\", \"SHALL\", \"SHALL\n> NOT\", \"SHOULD\", \"SH"
},
{
"path": "CIP-0068/ref_impl/README.md",
"chars": 703,
"preview": "# Minimal implementation of CIP-0068\n\n## Concept\n\nThe minting policy is a one-shot policy. Only single NFT (pair of `ref"
},
{
"path": "CIP-0068/ref_impl/offchain.ts",
"chars": 17255,
"preview": "// Lucid off-chain code: Mint an 222 NFT according to CIP-0068 standard\nimport {\n Blockfrost,\n Constr,\n Data,\n Lucid"
},
{
"path": "CIP-0068/ref_impl/onchain.hs",
"chars": 4442,
"preview": "-- PlutusTx on-chain code (PlutusV2)\n-- NOTE: The asset name labels are not finalized yet. This is only a proof of conce"
},
{
"path": "CIP-0069/README.md",
"chars": 7464,
"preview": "---\nCIP: 69\nTitle: Script Signature Unification\nCategory: Plutus\nAuthors:\n - Maksymilian 'zygomeb' Brodowicz <zygomeb@g"
},
{
"path": "CIP-0071/README.md",
"chars": 19877,
"preview": "---\nCIP: 71\nTitle: Non-Fungible Token (NFT) Proxy Voting Standard\nStatus: Proposed\nCategory: Tools\nAuthors:\n - Thaddeus"
},
{
"path": "CIP-0071/example/voting.html",
"chars": 6660,
"preview": "<html>\n <head>\n <script src=\"https://cdn.jsdelivr.net/npm/bootstrap@4.2.1/dist/js/bootstrap.min.js\" integrity=\"sha38"
},
{
"path": "CIP-0071/example/voting.js",
"chars": 18584,
"preview": "import * as helios from '@hyperionbt/helios';\n\nimport {Data, fromHex, toHex, getAddressDetails} from 'lucid-cardano';\n\n/"
},
{
"path": "CIP-0072/README.md",
"chars": 18920,
"preview": "---\nCIP: 72\nTitle: Cardano dApp Registration & Discovery\nStatus: Proposed\nCategory: Metadata\nAuthors: \n - Bruno Martins"
},
{
"path": "CIP-0072/version_2.0.0_offchain.json",
"chars": 9007,
"preview": "{\n \"$schema\": \"https://json-schema.org/draft/2020-12/schema\",\n \"type\":\"object\",\n \"properties\": {\n \"version"
},
{
"path": "CIP-0072/version_2.0.0_onchain.cddl",
"chars": 485,
"preview": "string = bstr .size (1..64) ; tstr / string from 1 up to 64 chars only\n\nsig_256 = bstr .size (64..64) ; 256 bytes signat"
},
{
"path": "CIP-0072/version_2.0.0_onchain.json",
"chars": 2222,
"preview": "{\n \"$schema\":\"https://json-schema.org/draft/2020-12/schema\",\n \"$id\":\"https://example.com/dApp.schema.json\",\n \"t"
},
{
"path": "CIP-0074/README.md",
"chars": 5498,
"preview": "---\nCIP: 74\nTitle: Set minPoolCost to 0\nAuthors:\n - Robin of Loxley <adarobinhood@tutanota.com>\nCategory: Ledger\nStatus:"
},
{
"path": "CIP-0075/README.md",
"chars": 14867,
"preview": "---\nCIP: 75\nTitle: Fair Stake Pool Rewards\nStatus: Proposed\nCategory: Ledger\nAuthors:\n - Tobias Fancee <tobiasfancee@"
},
{
"path": "CIP-0080/README.md",
"chars": 5531,
"preview": "---\nCIP: 80\nTitle: Transaction Serialization Deprecation Cycle\nStatus: Active\nCategory: Ledger\nAuthors:\n - Jared Cordua"
},
{
"path": "CIP-0082/README.md",
"chars": 18109,
"preview": "---\nCIP: 82\nTitle: Improved Rewards Scheme Parameters\nStatus: Proposed\nCategory: Ledger\nAuthors:\n - Tobias Fancee <to"
},
{
"path": "CIP-0083/README.md",
"chars": 18090,
"preview": "---\nCIP: 83\nTitle: Encrypted Transaction message/comment metadata (Addendum to CIP-0020)\nStatus: Active\nCategory: Metada"
},
{
"path": "CIP-0083/codesamples/democode-BASH.sh",
"chars": 1456,
"preview": "#!/bin/bash\n\n# --------------------------------------------------------------------------------------------\n# Demonstrat"
},
{
"path": "CIP-0083/codesamples/democode-NODEJS.js",
"chars": 4547,
"preview": "// -----------------------------------------------------------------------------------------------\n// Demonstration impl"
},
{
"path": "CIP-0083/codesamples/democode-PHP.php",
"chars": 2927,
"preview": "// ------------------------------------------------------------------------------------------\n// Demonstration implement"
},
{
"path": "CIP-0083/codesamples/democode-WEB.js",
"chars": 1726,
"preview": "// -----------------------------------------------------------------------------------------------\n// Democode for runni"
},
{
"path": "CIP-0083/codesamples/encrypted-message-metadata.json",
"chars": 295,
"preview": "{ \n \"674\":\n { \n \"enc\": \"basic\",\n \"msg\": \n [ \n \"U2FsdGVkX1"
},
{
"path": "CIP-0083/codesamples/normal-message-metadata.json",
"chars": 98,
"preview": "{\n \"674\": {\n \"msg\": [\"Invoice-No: 123456789\",\"Order-No: 7654321\",\"Email: john@doe.com\"]\n }\n}\n"
},
{
"path": "CIP-0083/format.cddl",
"chars": 332,
"preview": "string = text .size (0..64) ; utf-8\n\nmessage_details = \n {\n msg : [* string], \n ? enc : string\n }\n\n; msg = array"
},
{
"path": "CIP-0084/README.md",
"chars": 10046,
"preview": "---\nCIP: 84\nTitle: Cardano Ledger Evolution\nStatus: Active\nCategory: Meta\nAuthors: \n - Jared Corduan <jared.corduan@ioh"
},
{
"path": "CIP-0085/README.md",
"chars": 34768,
"preview": "---\nCIP: 85\nTitle: Sums-of-products in Plutus Core\nAuthors: \n - Michael Peyton Jones <michael.peyton-jones@iohk.io>\nImp"
}
]
// ... and 230 more files (download for full content)
About this extraction
This page contains the full source code of the cardano-foundation/CIPs GitHub repository, extracted and formatted as plain text for AI agents and large language models (LLMs). The extraction includes 430 files (5.1 MB), approximately 1.4M tokens, and a symbol index with 95 extracted functions, classes, methods, constants, and types. Use this with OpenClaw, Claude, ChatGPT, Cursor, Windsurf, or any other AI tool that accepts text input. You can copy the full output to your clipboard or download it as a .txt file.
Extracted by GitExtract — free GitHub repo to text converter for AI. Built by Nikandr Surkov.