CIP 1694 - An On-Chain Decentralized Governance Mechanism for Voltaire

AbstractWe propose a revision of Cardano's on-chain governance system to support the new requirements for Voltaire. The existing specialized governance support for protocol parameter updates and MIR certificates will be deprecated, and two new fields will be added to normal transaction bodies: governance actions, votes.


CIP: 1694 Title: A First Step Towards On-Chain Decentralized Governance Status: Proposed Category: Ledger Authors: - Jared Corduan [email protected] - Matthias Benkort [email protected] - Kevin Hammond [email protected] - Charles Hoskinson [email protected] - Andre Knispel [email protected] - Samuel Leathers [email protected] Discussions: - https://github.com/cardano-foundation/CIPs/pull/380 - https://forum.cardano.org/t/swarm-session-cip-1694/114453 - https://twitter.com/IOHK_Charles/status/1632211417221701632 - https://twitter.com/RichardMcCrackn/status/1632514347195850752 - https://twitter.com/RichardMcCrackn/status/1633135124500865024 - https://twitter.com/_KtorZ_/status/1632356766368382976 - https://twitter.com/_KtorZ_/status/1630087586193584128 - https://twitter.com/_KtorZ_/status/1631430933219012608 - https://twitter.com/technologypoet/status/1632158736985866241 - https://twitter.com/danny_cryptofay/status/1631606919071776768 - https://www.youtube.com/watch?v=2hCnmMG1__8 - https://www.youtube.com/watch?v=KiLhhOVXQOg Created: 2022-11-18 License: CC-BY-4.0

Abstract

We propose a revision of Cardano's on-chain governance system to support the new requirements for Voltaire. The existing specialized governance support for protocol parameter updates and MIR certificates will be removed, and two new fields will be added to normal transaction bodies for:

  1. governance actions
  2. votes

Any Cardano user will be allowed to submit a governance action. We also introduce three distinct governance bodies that have specific functions in this new governance framework:

  1. a constitutional committee
  2. a group of delegated representatives (henceforth called DReps)
  3. the stake pool operators (henceforth called SPOs)

Every governance action must be ratified by at least two of these three governance bodies using their on-chain votes. The type of action and the state of the governance system determines which bodies must ratify it.

Ratified actions are then enacted on-chain, following a set of well-defined rules.

As with stake pools, any Ada holder may register to be a DRep and so choose to represent themselves and/or others. Also, as with stake pools, Ada holders may, instead, delegate their voting rights to any other DRep. Voting rights will be based on the total Ada that is delegated, as a whole number of Lovelace.

The most crucial aspect of this proposal is therefore the notion of "one Lovelace = one vote".

Acknowledgements

<details> <summary><strong>First draft</strong></summary>

Many people have commented on and contributed to the first draft of this document, which was published in November 2022. We would especially like to thank the following people for providing their wisdom and insights:

  • Jack Briggs
  • Tim Harrison
  • Philip Lazos
  • Michael Madoff
  • Evangelos Markakis
  • Joel Telpner
  • Thomas Upfield

We would also like to thank those who have commented via Github and other channels.

</details> <details> <summary><strong>2023 Colorado Workshop (28/02 → 01/03)</strong></summary>

In addition, we would like to thank all the attendees of the workshop that was held in Longmont, Colorado on February 28th and March 1st 2023 for their valuable contributions to this CIP, and for their active championing of Cardano's vision for minimal viable governance. These include:

  • Adam Rusch, ADAO & Summon
  • Addie Girouard
  • Andrew Westberg
  • Darlington Wleh, LidoNation
  • Eystein Hansen
  • James Dunseith, Gimbalabs
  • Juana Attieh
  • Kenric Nelson
  • Lloyd Duhon, DripDropz
  • Marcus Jay Allen
  • Marek Mahut, 5 Binaries
  • Markus Gufler
  • Matthew Capps
  • Mercy, Wada
  • Michael Dogali
  • Michael Madoff
  • Patrick Tobler, NMKR
  • Philip Lazos
  • π Lanningham, SundaeSwap
  • Rick McCracken
  • Romain Pellerin
  • Sergio Sanchez Ferreros
  • Tim Harrison
  • Tsz Wai Wu
</details> <details> <summary><strong>2023 Mexico City, Mexico Workshop (20/05)</strong></summary>

In addition, we would like to thank all the attendees of the workshop that was held in Mexico City, Mexico on May 20th 2023 for their valuable contributions to this CIP, and for their active championing of Cardano's vision for minimal viable governance. These include:

  • Donovan Riaño
  • Cristian Jair Rojas
  • Victor Hernández
  • Ramón Aceves
  • Sergio Andrés Cortés
  • Isaías Alejandro Galván
  • Abigail Guzmán
  • Jorge Fernando Murguía
  • Luis Guillermo Santana
</details> <details> <summary><strong>2023 Buenos Aires, Argentina Workshop (20/05)</strong></summary>

In addition, we would like to thank all the attendees of the workshop that was held in Buenos Aires, Argentina on May 20th 2023 for their valuable contributions to this CIP, and for their active championing of Cardano's vision for minimal viable governance. These include:

  • Lucas Macchiavelli
  • Alejando Pestchanker
  • Juan Manuel Castro Pippo
  • Federico Weill
  • Jose Otegui
  • Mercedes Ruggeri
  • Mauro Andreoli
  • Elias Aires
  • Jorge Nasanovsky
  • Ulises Barreiro
  • Martin Ochoa
  • Facundo Lopez
  • Vanina Estrugo
  • Luca Pestchanker
</details> <details> <summary><strong>2023 Johannesburg, South Africa Workshop (25/05)</strong></summary>

In addition, we would like to thank all the attendees of the workshop that was held in Johannesburg, South Africa on May 25th 2023 for their valuable contributions to this CIP, and for their active championing of Cardano's vision for minimal viable governance. These include:

  • Celiwe Ngwenya
  • Bernard Sibanda
  • Dumo Mbobo
  • Shaolyn Dzwedere
  • Kunoshe Muchemwa
  • Siphiwe Mbobo
  • Lucas Sibindi
  • DayTapoya
  • Mdu Ngwenya
  • Lucky Khumalo
  • Skhangele Malinga
  • Joyce Ncube
  • Costa Katenhe
  • Bramwell Kasanga
  • Precious Abimbola
  • Ethel Q Tshuma
  • Panashe Sibanda
  • Radebe Tefo
  • Kaelo Lentsoe
  • Richmond Oppong
  • Israel Ncube
  • Sikhangele Malinga
  • Nana Safo
  • Ndaba Delsie
  • Collen Tshepang
  • Dzvedere Shaolyn
  • Thandazile Sibanda
  • Ncube Joyce
  • Lucas Sibindi
  • Pinky Ferro
  • Ishmael Ntuta
  • Khumalo Lucky
  • Fhulufelo
  • Thwasile Ngwenya
  • Kunashe Muchemwa
  • Dube Bekezela
  • Tinyiko Baloi
  • Dada Nomathemba
</details> <details> <summary><strong>2023 Bogota, Colombia Workshop (27/05)</strong></summary>

In addition, we would like to thank all the attendees of the workshop that was held in Bogota, Colombia on May 27th 2023 for their valuable contributions to this CIP, and for their active championing of Cardano's vision for minimal viable governance. These include:

  • Alvaro Moncada
  • Jaime Andres Posada Castro
  • Jose Miguel De Gamboa
  • Nicolas Gomez
  • Luis Restrepo (Moxie)
  • Juanita Jaramillo R.
  • Daniel Vanegas
  • Ernesto Rafael Pabon Moreno
  • Carlos Eduardo Escobar
  • Manuel Fernando Briceño
  • Sebastian Pabon
</details> <details> <summary><strong>2023 Caracas, Venezuela Workshop (27/05)</strong></summary>

In addition, we would like to thank all the attendees of the workshop that was held in Caracas, Venezuela on May 27th 2023 for their valuable contributions to this CIP, and for their active championing of Cardano's vision for minimal viable governance. These include:

  • Jean Carlo Aguilar
  • Wilmer Varón
  • José Erasmo Colmenares
  • David Jaén
  • Félix Dávila
  • Yaneth Duarte
  • Nando Vitti
  • Wilmer Rojas
  • Andreina García
  • Carmen Galban
  • Osmarlina Agüero
  • Ender Linares
  • Carlos A. Palacios R
  • Dewar Rodríguez
  • Lennys Blanco
  • Francys García
  • Davidson Arenas
</details> <details> <summary><strong>2023 Manizales, Colombia Workshop (27/05)</strong></summary>

In addition, we would like to thank all the attendees of the workshop that was held in Manizales, Colombia on May 27th 2023 for their valuable contributions to this CIP, and for their active championing of Cardano's vision for minimal viable governance. These include:

  • Yaris Cruz
  • Yaneth Duarte
  • Ciro Gelvez
  • Kevin Chacon
  • Juan Sierra
  • Caue Chianca
  • Sonia Malagon
  • Facundo Ramirez
  • Hope R.
</details> <details> <summary><strong>2023 Addis Ababa, Ethiopia Workshop (27/05 & 28/5)</strong></summary>

In addition, we would like to thank all the attendees of the workshop that was held in Addis Ababa, Ethiopia on May 27th and 28th 2023 for their valuable contributions to this CIP, and for their active championing of Cardano's vision for minimal viable governance. These include:

  • Kaleb Dori
  • Eyassu Birru
  • Matthew Thornton
  • Tamir Kifle
  • Kirubel Tabu
  • Bisrat Miherete
  • Emmanuel Khatchadourian
  • Tinsae Teka
  • Yoseph Ephrem
  • Yonas Eshetu
  • Hanna Kaleab
  • Tinsae Teka
  • Robee Meseret
  • Matias Tekeste
  • Eyasu Birhanu
  • yonatan berihun
  • Nasrallah Hassan
  • Andinet Assefa
  • Tewodros Sintayehu
  • KIDUS MENGISTEAB
  • Djibril Konate
  • Nahom Mekonnen
  • Eyasu Birhanu
  • Eyob Aschenaki
  • Tinsae Demissie
  • Yeabsira Tsegaye
  • Tihitna Miroche
  • Mearaf Tadewos
  • Yab Mitiku
  • Habtamu Asefa
  • Dawit Mengistu
  • Nebiyu Barsula
  • Nebiyu Sultan
  • Nathan Samson
</details> <details> <summary><strong>2023 Kyoto and Fukuoka, Japan Workshop (27/05 & 10/06 )</strong></summary>

In addition, we would like to thank all the attendees of the workshop that was held in Kyoto and Fukuoka, Japan on May 27th and June 10th 2023 for their valuable contributions to this CIP, and for their active championing of Cardano's vision for minimal viable governance. These include:

  • Arimura
  • Hidemi
  • Nagamaru(SASApool)
  • shiodome47(SODMpool)
  • Wakuda(AID1pool)
  • Yuta(Yuki Oishi)
  • Andrew
  • BANCpool
  • Miyatake
  • Muen
  • Riekousagi
  • SMAN8(SA8pool)
  • Tatsuya
  • カッシー
  • ポンタ
  • リサ
  • Mako
  • Ririco
  • ながまる
  • Baku
  • マリア
  • たりふん
  • JUNO
  • Kinoko
  • Chikara
  • ET
  • Akira555
  • Kent
  • Ppp
  • Shiodome47
  • Sam
  • ポール
  • Concon
  • Sogame
  • ハンド
  • Demi
  • Nonnon
  • banC
  • SMAN8(SA8pool)
  • りんむ
  • Kensin
  • りえこうさぎ
  • アダマンタイト
  • の/ゆすけ
  • MUEN
  • いちごだいふく
  • Ranket
  • A.yy
  • N S
  • Kazuya
  • Daikon
</details> <details> <summary><strong>2023 Monterey, California Workshop (28/05)</strong></summary>

In addition, we would like to thank all the attendees of the workshop that was held in Monterey, California on May 28th 2023 for their valuable contributions to this CIP, and for their active championing of Cardano's vision for minimal viable governance. These include:

  • Shane Powser
  • Rodrigo Gomez
  • Adam K. Dean
  • John C. Valdez
  • Kyle Solomon
  • Erick "Mag" Magnana
  • Bryant Austin
  • John Huthmaker
  • Ayori Selassie
  • Josh Noriega
  • Matthias Sieber
</details> <details> <summary><strong>2023 Tlaxcala, Mexico Workshop (01/06)</strong></summary>

In addition, we would like to thank all the attendees of the workshop that was held in Tlaxcala, Mexico on June 1st 2023 for their valuable contributions to this CIP, and for their active championing of Cardano's vision for minimal viable governance. These include:

  • Victor Hernández
  • Cristian Jair Rojas
  • Miriam Mejia
  • Josmar Cabañas
  • Lizbet Delgado
  • José Alberto Sánchez
  • Fátima Valeria Zamora
  • Julio César Montiel
  • Jesús Pérez
  • José Adrián López
  • Lizbeth Calderón
  • Zayra Molina
  • Nayelhi Pérez
  • Josué Armas
  • Diego Talavera
  • Darían Gutiérrez
</details> <details> <summary><strong>2023 LATAM Virtual Workshop (03/06)</strong></summary>

In addition, we would like to thank all the attendees of the workshop that was held in LATAM Virtual on June 3rd 2023 for their valuable contributions to this CIP, and for their active championing of Cardano's vision for minimal viable governance. These include:

  • Juan Sierra
  • @CaueChianca
  • Ernesto Rafael
  • Pabon Moreno
  • Sonia Malagon
  • Facundo Ramírez
  • Mercedes Ruggeri
  • Hope R.
  • Yaris Cruz
  • Yaneth Duarte
  • Ciro Gélvez
  • Kevin Chacon
  • Juanita Jaramillo
  • Sebastian Pabon
</details> <details> <summary><strong>2023 Worcester, Massachusetts Workshop (08/06)</strong></summary>

In addition, we would like to thank all the attendees of the workshop that was held in Worcester, Massachusetts on June 8th 2023 for their valuable contributions to this CIP, and for their active championing of Cardano's vision for minimal viable governance. These include:

  • CardanoSharp
  • Kenric Nelson
  • Matthias Sieber
  • Roberto Mayen
  • Ian Burzynski
  • omdesign
  • Chris Gianelloni
</details> <details> <summary><strong>2023 Chicago, Illinois Workshop (10/06)</strong></summary>

In addition, we would like to thank all the attendees of the workshop that was held in Chicago, Illinois on June 10th 2023 for their valuable contributions to this CIP, and for their active championing of Cardano's vision for minimal viable governance. These include:

  • Adam Rusch
  • Jose Martinez
  • Michael McNulty
  • Vanessa Villanueva Collao
  • Maaz Jedh
</details> <details> <summary><strong>2023 Virtual Workshop (12/06)</strong></summary>

In addition, we would like to thank all the attendees of the workshop that was held virtually on June 12th 2023 for their valuable contributions to this CIP, and for their active championing of Cardano's vision for minimal viable governance. These include:

  • Rojo Kaboti
  • Tommy Frey
  • Tevo Saks
  • Slate
  • UBIO OBU
</details> <details> <summary><strong>2023 Toronto, Canada Workshop (15/06)</strong></summary>

In addition, we would like to thank all the attendees of the workshop that was held in Toronto, Canada on June 15th 2023 for their valuable contributions to this CIP, and for their active championing of Cardano's vision for minimal viable governance. These include:

  • John MacPherson
  • Lawrence Ley
</details> <details> <summary><strong>2023 Philadelphia, Pennsylvania Workshop (17/06)</strong></summary>

In addition, we would like to thank all the attendees of the workshop that was held in Philadelphia, Pennsylvania on June 17th 2023 for their valuable contributions to this CIP, and for their active championing of Cardano's vision for minimal viable governance. These include:

  • NOODZ
  • Jarhead
  • Jenny Brito
  • Shepard
  • BONE Pool
  • type_biggie
  • FLAWWD
  • A.I. Scholars
  • Eddie
  • Joker
  • Lex
  • Jerome
  • Joey
  • SwayZ
  • Cara Mia
  • PHILLY 1694
</details> <details> <summary><strong>2023 Santiago de Chile Workshop (17/06)</strong></summary>

In addition, we would like to thank all the attendees of the workshop that was held in Santiago de Chile on June 17th 2023 for their valuable contributions to this CIP, and for their active championing of Cardano's vision for minimal viable governance. These include:

  • Rodrigo Oyarsun
  • Sebastián Aravena
  • Musashi Fujio
  • Geo Gavo
  • Lucía Escobar
  • Juan Cruz Franco
  • Natalia Rosa
  • Cristian M. García
  • Alejandro Montalvo
</details> <details> <summary><strong>2023 Virtual Workshop (17/06)</strong></summary>

In addition, we would like to thank all the attendees of the workshop that was held virtually on June 17th 2023 for their valuable contributions to this CIP, and for their active championing of Cardano's vision for minimal viable governance. These include:

  • Juana Attieh
  • Nadim Karam
  • Amir Azem
  • Rami Hanania
  • LALUL Stake Pool
  • HAWAK Stake Pool
</details> <details> <summary><strong>2023 Taipai, Taiwan Workshop (18/06)</strong></summary>

In addition, we would like to thank all the attendees of the workshop that was held in Taipai, Taiwan on June 18th 2023 for their valuable contributions to this CIP, and for their active championing of Cardano's vision for minimal viable governance. These include:

  • Michael Rogero
  • Ted Chen
  • Mic
  • Jeremy Firster
  • Eric Tsai
  • Dylan Chiang
  • JohnsonCai
  • DavidCHIEN
  • Zach Gu
  • Jimmy WANG
  • JackTsai
  • Katherine Hung
  • Will Huang
  • Kwicil
</details> <details> <summary><strong>2023 Midgard Vikingcenter Horten, Norway Workshop (19/06)</strong></summary>

In addition, we would like to thank all the attendees of the workshop that was held in Midgard Vikingcenter Horten, Norway on June 19th 2023 for their valuable contributions to this CIP, and for their active championing of Cardano's vision for minimal viable governance. These include:

  • Daniel D. Johnsen
  • Thomas Lindseth
  • Eystein Hansen
  • Gudbrand Tokerud
  • Lally McClay
  • $trym
  • Arne Rasmussen
  • Lise WesselTVVIN
  • Bjarne
  • Jostein Aanderaa
  • Ken-Erik Ølmheim
  • DimSum
</details> <details> <summary><strong>2023 Virtual Workshop (19/06)</strong></summary>

In addition, we would like to thank all the attendees of the workshop that was held virtually on June 19th 2023 for their valuable contributions to this CIP, and for their active championing of Cardano's vision for minimal viable governance. These include:

  • Nicolas Cerny
  • Nils Peuser
  • Riley Kilgore
  • Alejandro Almanza
  • Jenny Brito
  • John C. Valdez
  • Rhys
  • Thyme
  • Adam Rusch
  • Devryn
</details> <details> <summary><strong>2023 New York City, New York Workshop (20/06)</strong></summary>

In addition, we would like to thank all the attendees of the workshop that was held in New York City, New York on June 20th 2023 for their valuable contributions to this CIP, and for their active championing of Cardano's vision for minimal viable governance. These include:

  • John Shearing
  • Geoff Shearing
  • Daniela Balaniuc
  • SDuffy
  • Garry Golden
  • Newman
  • Emmanuel Batse
  • Ebae
  • Mojira
</details> <details> <summary><strong>2023 La Cumbre, Argentina Workshop (23/06)</strong></summary>

In addition, we would like to thank all the attendees of the workshop that was held in La Cumbre, Argentina on June 23rd 2023 for their valuable contributions to this CIP, and for their active championing of Cardano's vision for minimal viable governance. These include:

  • Ulises Barreiro
  • Daniel F. Rodriguez
  • Dominique Gromez
  • Leandro Chialvo
  • Claudia Vogel
  • Guillermo Lucero
  • Funes, Brian Carrasco
  • Melisa Carrasco
  • Carlos Carrasco
</details> <details> <summary><strong>2023 Minneapolis, Minnesota Workshop (23/06)</strong></summary>

In addition, we would like to thank all the attendees of the workshop that was held in Minneapolis, Minnesota on June 23rd 2023 for their valuable contributions to this CIP, and for their active championing of Cardano's vision for minimal viable governance. These include:

  • Stephanie King
  • Darlington Wleh
</details> <details> <summary><strong>2023 La Plata, Argentina Workshop (23/06)</strong></summary>

In addition, we would like to thank all the attendees of the workshop that was held in La Plata, Argentina on June 23rd 2023 for their valuable contributions to this CIP, and for their active championing of Cardano's vision for minimal viable governance. These include:

  • Mauro Andreoli
  • Rodolfo Miranda
  • Agustin Francella
  • Federico Sting
  • Elias Aires
  • Lucas Macchiavelli
  • Pablo Hernán Mazzitelli
</details> <details> <summary><strong>2023 Puerto Madryn, Argentina Workshop (23/06)</strong></summary>

In addition, we would like to thank all the attendees of the workshop that was held in Puerto Madryn, Argentina on June 23rd 2023 for their valuable contributions to this CIP, and for their active championing of Cardano's vision for minimal viable governance. These include:

  • Andres Torres Borda
  • Federico Ledesma Calatayud
  • Maximiliano Torres
  • Federico Prado
  • Domingo Torres
  • Floriana Pérez Barria
  • Martin Real
  • Florencia García
  • Roberto Neme
</details> <details> <summary><strong>2023 Accra, Ghana Workshop (24/06)</strong></summary>

In addition, we would like to thank all the attendees of the workshop that was held in Accra, Ghana on June 24th 2023 for their valuable contributions to this CIP, and for their active championing of Cardano's vision for minimal viable governance. These include:

  • Wada
  • Laurentine
  • Christopher A.
  • Nathaniel D.
  • Edufua
  • Michael
  • Augusta
  • Jeremiah
  • Boaz
  • Mohammed
  • Richmond O.
  • Ezekiel
  • Megan
  • Josue
  • Michel T.
  • Bineta
  • Afia O.
  • Mercy
  • Enoch
  • Kofi
  • Awura
  • Emelia
  • Richmond S.
  • Solomon
  • Phillip
  • Faakor
  • Manfo
  • Josh
  • Daniel
  • Mermose
</details> <details> <summary><strong>2023 Virtual Workshop (24/06)</strong></summary>

In addition, we would like to thank all the attendees of the workshop that was held virtually on June 24th 2023 for their valuable contributions to this CIP, and for their active championing of Cardano's vision for minimal viable governance. These include:

  • Jonas Riise
  • Thomas Lindseth
  • André "Eilert" Eilertsen
  • Eystein Hansen
</details> <details> <summary><strong>2023 Seoul, South Korea Workshop (24/06)</strong></summary>

In addition, we would like to thank all the attendees of the workshop that was held in Seoul, South Korea on June 24th 2023 for their valuable contributions to this CIP, and for their active championing of Cardano's vision for minimal viable governance. These include:

  • Oscar Hong (JUNGI HONG)
  • SPO_COOL (Kevin Kordano)
  • SPO_KTOP (KT OH)
  • WANG JAE LEE
  • JAE HYUN AN
  • INYOUNG MOON (Penny)
  • HOJIN JEON
  • SEUNG KYU BAEK
  • SA SEONG MAENG
  • JUNG MYEONG HAN
  • BRIAN KIM
  • JUNG HOON KIM
  • SEUNG WOOK JUNG (Peter)
  • HYUNG WOO PARK
  • EUN JAE CHOI
  • NA GYEONG KIM
  • JADEN CHOI
</details> <details> <summary><strong>2023 Abu Dhabi, UAE Workshop (25/06)</strong></summary>

In addition, we would like to thank all the attendees of the workshop that was held in Abu Dhabi, UAE on June 25th 2023 for their valuable contributions to this CIP, and for their active championing of Cardano's vision for minimal viable governance. These include:

  • Amir Azem
  • Ian Arden
  • Madina Abdibayeva
  • BTBF (Yu Kagaya)
  • محمد الظاهري
  • Tegegne Tefera
  • Rami Hanania
  • Tania Debs
  • Khalil Jad
  • Mohamed Jamal
  • Ruslan Yakubov
  • OUSHEK Mohamed eisa
  • Shehryar
  • Wael Ben Younes
  • Santosh Ray
  • Juana Attieh
  • Nadim Karam
  • DubaistakePool
  • HAWAK Pool
  • LALKUL Stake Pools
</details> <details> <summary><strong>2023 Williamsburg, New York Workshop (25/06)</strong></summary>

In addition, we would like to thank all the attendees of the workshop that was held in Williamsburg, New York on June 25th 2023 for their valuable contributions to this CIP, and for their active championing of Cardano's vision for minimal viable governance. These include:

  • Pi
  • Joseph
  • Skyler
  • Forrest
  • Gabriel
  • Newman
</details> <details> <summary><strong>2023 Lagos, Nigeria Workshop (28/06)</strong></summary>

In addition, we would like to thank all the attendees of the workshop that was held in Lagos, Nigeria on June 28th 2023 for their valuable contributions to this CIP, and for their active championing of Cardano's vision for minimal viable governance. These include:

  • Jonah Benson
  • Augusta
  • Ubio Obu
  • Olumide Hrosuosegbe
  • Veralyn Chinenye
  • Ona Ohimer
  • William Ese
  • Ruth Usoro
  • William P
  • Esther Simi
  • Daniel Effiom
  • Akinkurai Toluwalase
</details> <details> <summary><strong>2023 Sao Paulo, Brazil Workshop (01/07)</strong></summary>

In addition, we would like to thank all the attendees of the workshop that was held in Sao Paulo, Brazil on July 1st 2023 for their valuable contributions to this CIP, and for their active championing of Cardano's vision for minimal viable governance. These include:

  • Otávio Lima
  • Rodrigo Pacini
  • Maria Carmo
  • Cauê Chianca
  • Daniela Alves
  • Jose Lins Dias
  • Felipe Barcelos
  • Rosana Melo
  • Johnny Oliveira
  • Lucas Ravacci
  • Cristofer Ramos
  • Weslei Menck
  • Leandro Tsutsumi
  • Izaias Pessoa
  • Gabriel Melo
  • Yuri Nabeshima
  • Alexandre Fernandes
  • Vinicius Ferreiro
  • Lucas Fernandes
  • Alessandro Benicio
  • Mario Cielho
  • Lory Fernandes Lima
  • Larissa Nogueira
  • Latam Cardano Community
</details> <details> <summary><strong>2023 Brazil Virtual Workshop (04/07)</strong></summary>

In addition, we would like to thank all the attendees of the workshop that was held in Brazil on July 4th 2023 for their valuable contributions to this CIP, and for their active championing of Cardano's vision for minimal viable governance. These include:

  • Lincon Vidal
  • Thiago da Silva Nunes
  • Rodrigo Pacini
  • Livia Corcino de Albuquerque
  • Cauê Chianca
  • Otávio Lima
</details>

Motivation: why is this CIP necessary?

Goal

We're heading into the age of Voltaire, laying down the foundations for decentralized decision-making. This CIP describes a mechanism for on-chain governance that will underpin the Voltaire phase of Cardano. The CIP builds on and extends the original Cardano governance scheme that was based on a fixed number of governance keys. It aims to provide a first step that is both valuable and, importantly, is also technically achievable in the near term as part of the proposed Voltaire governance system.

It also seeks to act as a jumping-off point for continuing community input, including on appropriate threshold settings and other on-chain settings.

Subsequent proposals may adapt and extend this proposal to meet emerging governance needs.

Current governance mechanism design

The on-chain Cardano governance mechanism that was introduced in the Shelley ledger era is capable of:

  1. modifying the values of the protocol parameters (including initiating "hard forks")
  2. transferring Ada out of the reserves and the treasury (and also moving Ada between the reserves and the treasury)

In the current scheme, governance actions are initiated by special transactions that require Quorum-Many authorizations from the governance keys (5 out of 7 on the Cardano mainnet)1. Fields in the transaction body provide details of the proposed governance action: either i) protocol parameter changes; or ii) initiating funds transfers. Each transaction can trigger both kinds of governance actions, and a single action can have more than one effect (e.g. changing two or more protocol parameters).

Properly authorized governance actions are applied on an epoch boundary (they are enacted).

Hard Forks

One of the protocol parameters is sufficiently significant to merit special attention: changing the major protocol version enables Cardano to enact controlled hard forks. This type of protocol parameter update therefore has a special status, since stake pools must upgrade their nodes so they can support the new protocol version once the hard fork is enacted.

Shortcomings of the Shelley governance design

The Shelley governance design was intended to provide a simple, transitional approach to governance. This proposal aims to address a number of shortcomings with that design that are apparent as we move into Voltaire.

  1. The Shelley governance design gives no room for active on-chain participation of Ada holders. While changes to the protocol are usually the results of discussions with selected community actors, the process is currently driven mainly by the founding entities. Ensuring that everyone can voice their concern is cumbersome, and can be perceived as arbitrary at times.

  2. Movements from the treasury constitute a critical and sensitive topic. However, they can be hard to track. It is important to have more transparency and more layers of control over these movements.

  3. While they need to be treated specially by SPOs, hard forks are not differentiated from other protocol parameter changes.

  4. Finally, while there is currently a somewhat common vision for Cardano that is shared by its founding entities and also by many community members, there is no clearly defined document where these guiding principles are recorded. It makes sense to leverage the Cardano blockchain to record the shared Cardano ethos in an immutable fashion, as a formal Cardano Constitution.

Out of scope

The following topics are considered to be out of the scope of this CIP.

The contents of the constitution

This CIP focuses only on on-chain mechanisms. The provisions of the initial constitution are extremely important, as are any processes that will allow it to be amended. These merit their own separate and focused discussion.

The membership of the constitutional committee

This is an off-chain issue.

Legal issues

Any potential legal enforcement of either the Cardano protocol or the Cardano Constitution are completely out of scope for this CIP.

Off chain standards for governance actions

The Cardano community must think deeply about the correct standards and processes for handling the creation of the governance actions that are specified in this CIP. In particular, the role of Project Catalyst in creating treasury withdrawal actions is completely outside the scope of this CIP.

Ada holdings and delegation

How any private companies, public or private institutions, individuals etc. choose to hold or delegate their Ada, including delegation to stake pools or DReps, is outside the scope of this CIP.

Specification

The Cardano Constitution

The Cardano Constitution is a text document that defines Cardano's shared values and guiding principles. At this stage, the Constitution is an informational document that unambiguously captures the core values of Cardano and acts to ensure its long-term sustainability. At a later stage, we can imagine the Constitution perhaps evolving into a smart-contract based set of rules that drives the entire governance framework. For now, however, the Constitution will remain an off-chain document whose hash digest value will be recorded on-chain. As discussed above, the Constitution is not yet defined and its content is out of scope for this CIP.

<!--------------------------- Constitutional committee ------------------------>

The constitutional committee

We define a constitutional committee which represents a set of individuals or entities (each associated with a Ed25519 or native or Plutus script credential) that are collectively responsible for ensuring that the Constitution is respected.

Though it cannot be enforced on-chain, the constitutional committee is only supposed to vote on the constitutionality of governance actions (which should thus ensure the long-term sustainability of the blockchain) and should be replaced (via the no confidence action) if they overstep this boundary. Said differently, there is a social contract between the constitutional committee and the actors of the network. Although the constitutional committee could reject certain governance actions (by voting 'No' on them), they should only do so when those governance actions are in conflict with the Constitution.

For example, if we consider the hypothetical Constitution rule "The Cardano network must always be able to produce new blocks", then a governance action that would reduce the maximum block size to 0 would be, in effect, unconstitutional and so might not be ratified by the constitutional committee. The rule does not, however, specify the smallest acceptable maximum block size, so the constitutional committee would need to determine this number and vote accordingly.

State of no-confidence

The constitutional committee is considered to be in one of the following two states at all times:

  1. a normal state (i.e. a state of confidence)
  2. a state of no-confidence

In a state of no-confidence, the current committee is no longer able to participate in governance actions and must be replaced before any governance actions can be ratified (see below).

Constitutional committee keys

The constitutional committee will use a hot and cold key setup, similar to the existing "genesis delegation certificate" mechanism.

Replacing the constitutional committee

The constitutional committee can be replaced via a specific governance action ("New constitutional committee", described below) that requires the approval of both the SPOs and the DReps. The threshold for ratification might be different depending on if the governance is in a state of confidence or a state of no confidence.

The new constitutional committee could, in principle, be identical to or partially overlap the outgoing committee as long as the action is properly ratified. This might happen, for example, if the electorate has collective confidence in all or part of the committee and wishes to extend its term of office.

Size of the constitutional committee

Unlike the Shelley governance design, the size of the constitutional committee is not fixed and can be any nonnegative number. It may be changed whenever a new committee is elected ("New constitutional committee and/or threshold"). Likewise, the committee threshold (the fraction of committee Yes votes that are required to ratify governance actions) is not fixed and can also be varied by the governance action. This gives a great deal of flexibility to the composition of the committee. In particular, it is possible to elect an empty committee if the community wishes to abolish the constitutional committee entirely. Note that this is different from a state of no-confidence and still constitutes a governance system capable of enacting proposals.

There will be a new protocol parameter for the minimal size of the committee, itself a nonnegative number.

Terms

Each newly elected constitutional committee will have a term. Per-member terms allow for a rotation scheme, such as a third of the committee expiring every year. Expired members can no longer vote. Member can also willingly resign early, which will be marked on-chain as an expired member.

If the number of non-expired committee members falls below the minimal size of the committee, the constitutional committee will be unable to ratify governance actions. This means that only governance actions that don't require votes from the constitutional committee can still be ratified.

For example, a committee of size five with a threshold of 3/5 a minimum size of three and two expired members can still pass governance actions if two non-expired members vote Yes. However, if one more member expires then the constitutional committee becomes unable to ratify any more governance actions.

The maximum term is a governance protocol parameter, specified as a number of epochs. During a state of no-confidence, no action can be ratified, so the committee should plan for its own replacement if it wishes to avoid disruption.

Proposal policy

While the constitution is an informal, off-chain document, there will also be an optional script that can enforce some guidelines. This script acts to supplement the constitutional committee by restricting some proposal types. For example, if the community wishes to have some hard rules for the treasury that cannot be violated, a script that enforces these rules can be voted in as the proposal policy.

The proposal policy applies only to protocol parameter update and treasury withdrawal proposals.

<!--------------------------- DReps ------------------------>

Delegated representatives (DReps)

Warning CIP-1694 DReps should not be conflated with Project Catalyst DReps.

<!-- TODO find another name that still points to liquid democracy. -->

Pre-defined DReps

In order to participate in governance, a stake credential must be delegated to a DRep. Ada holders will generally delegate their voting rights to a registered DRep that will vote on their behalf. In addition, two pre-defined DRep options are available:

  • Abstain

    If an Ada holder delegates to Abstain, then their stake is actively marked as not participating in governance.

    The effect of delegating to Abstain on chain is that the delegated stake will not be considered to be a part of the active voting stake. However, the stake will be considered to be registered for the purpose of the incentives that are described in Incentives for Ada holders to delegate voting stake.

  • No Confidence

    If an Ada holder delegates to No Confidence, then their stake is counted as a Yes vote on every No Confidence action and a No vote on every other action. The delegated stake will be considered part of the active voting stake. It also serves as a directly auditable measure of the confidence of Ada holders in the constitutional committee.

Note The pre-defined DReps do not cast votes inside of transactions, their behavior is accounted for at the protocol level. The Abstain DRep may be chosen for a variety of reasons, including the desire to not participate in the governance system.

Note Any Ada holder may register themselves as a DRep and delegate to themselves if they wish to actively participate in voting.

Registered DReps

In Voltaire, existing stake credentials will be able to delegate their stake to DReps for voting purposes, in addition to the current delegation to stake pools for block production. DRep delegation will mimic the existing stake delegation mechanisms (via on-chain certificates). Similarly, DRep registration will mimic the existing stake registration mechanisms. Additionally, registered DReps will need to vote regularly to still be considered active. Specifically, if a DRep does not submit any votes for drepActivity-many epochs, the DRep is considered inactive, where drepActivity is a new protocol parameter. Inactive DReps do not count towards the active voting stake anymore, and can become active again for drepActivity-many epochs by voting on any governance actions. The reason for marking DReps as inactive is so that DReps who stop participating but still have stake delegated to them do not eventually leave the system in a state where no governance action can pass.

Registered DReps are identified by a credential that can be either:

  • A verification key (Ed25519)
  • A native or Plutus script

The blake2b-224 hash digest of a serialized DRep credential is called the DRep ID.

The following new types of certificates will be added for DReps: DRep registration certificates, DRep retirement certificates, and vote delegation certificates.

DRep registration certificates

DRep registration certificates include:

  • a DRep ID
  • a deposit
  • an optional anchor

An anchor is a pair of:

  • a URL to a JSON payload of metadata
  • a hash of the contents of the metadata URL

The structure and format of this metadata is deliberately left open in this CIP. The on-chain rules will not check either the URL or the hash. Client applications should, however, perform the usual sanity checks when fetching content from the provided URL.

DRep retirement certificates

DRep retirement certificates include:

  • a DRep ID

Note that a DRep is retired immediately upon the chain accepting a retirement certificate, and the deposit is returned as part of the transaction that submits the retirement certificate (the same way that stake credential registration deposits are returned).

Vote delegation certificates

Vote delegation certificates include:

  • the DRep ID to which the stake should be delegated
  • the stake credential for the delegator

Note

DRep delegation always maps a stake credential to a DRep credential. This means that a DRep cannot delegate voting stake to another DRep.

Certificate authorization schemes

The authorization scheme (i.e. which signatures are required for registration, retirement or delegation) mimics the existing stake delegation certificate authorization scheme.

<!-- TODO: Provide CBOR specification in the annexe for those new certificates. -->

New stake distribution for DReps

In addition to the existing per-stake-credential distribution and the per-stake-pool distribution, the ledger will now also determine the per-DRep stake distribution. This distribution will determine how much stake each vote from a DRep is backed by.

Warning

Unlike the distribution that is used for block production, we will always use the most current version of the per-DRep stake distribution as given on the epoch boundary.

This means that for any topic which individual voters care deeply about, they have time to delegate to themselves as a DRep and vote directly. However, it means that there may be a difference between the stake that is used for block production and the stake that is used for voting in any given epoch.

Incentives for Ada holders to delegate voting stake

There will be a short bootstrapping phase during which rewards will be earned for stake delegation etc. and may be withdrawn at any time. After this phase, although rewards will continue to be earned for block delegation etc., reward accounts will be blocked from withdrawing any rewards unless their associated stake credential is also delegated to a DRep. This helps to ensure high participation, and so, legitimacy.

Note

Even though rewards cannot be withdrawn, they are not lost. As soon as a stake credential is delegated (including to a pre-defined DRep), the rewards can be withdrawn.

DRep incentives

DReps arguably need to be compensated for their work. Research on incentive models is still ongoing, and we do not wish to hold up implementation of this CIP while this is resolved.

Our interim proposal is therefore to escrow Lovelace from the existing Cardano treasury until this extremely important decision can be agreed on by the community, through the on-chain governance mechanism that is being constructed.

Alternatively, DReps could pay themselves through instances of the "Treasury withdrawal" governance action. Such an action would be auditable on-chain, and should reflect an off-chain agreement between DReps and delegators.

<!--------------------------- DReps ------------------------> <!--------------------------- Governance Actions ------------------------>

Governance actions

We define seven different types of governance actions. A governance action is an on-chain event that is triggered by a transaction and has a deadline after which it cannot be enacted.

  • An action is said to be ratified when it gathers enough votes in its favor (through the rules and parameters that are detailed below).
  • An action that fails to be ratified before its deadline is said to have expired.
  • An action that has been ratified is said to be enacted once it has been activated on the network.
ActionDescription
1. Motion of no-confidenceA motion to create a state of no-confidence in the current constitutional committee
2. New constitutional committee and/or threshold and/or termsChanges to the members of the constitutional committee and/or to its signature threshold and/or terms
3. Update to the Constitution or proposal policyA modification to the Constitution or proposal policy, recorded as on-chain hashes
4. Hard-Fork2 InitiationTriggers a non-backwards compatible upgrade of the network; requires a prior software upgrade
5. Protocol Parameter ChangesAny change to one or more updatable protocol parameters, excluding changes to major protocol versions ("hard forks")
6. Treasury WithdrawalsWithdrawals from the treasury
7. InfoAn action that has no effect on-chain, other than an on-chain record

Any Ada holder can submit a governance action to the chain. They must provide a deposit of govActionDeposit Lovelace, which will be returned when the action is finalized (whether it is ratified or has expired). The deposit amount will be added to the deposit pot, similar to stake key deposits. It will also be counted towards the stake of the reward address it will be paid back to, to not reduce the submitter's voting power to vote on their own (and competing) actions.

If a proposal policy is present, the transaction must include that policy in the witness set either directly, or via reference inputs, and any other requirements that the proposal policy makes must be satisfied.

Note that a motion of no-confidence is an extreme measure that enables Ada holders to revoke the power that has been granted to the current constitutional committee.

Note A single governance action might contain multiple protocol parameter updates. Many parameters are inter-connected and might require moving in lockstep.

Ratification

Governance actions are ratified through on-chain voting actions. Different kinds of governance actions have different ratification requirements but always involve two of the three governance bodies, with the exception of a hard-fork initiation and security-relevant protocol parameters, which requires ratification by all governance bodies. Depending on the type of governance action, an action will thus be ratified when a combination of the following occurs:

  • the constitutional committee approves of the action (the number of members who vote Yes meets the threshold of the constitutional committee)
  • the DReps approve of the action (the stake controlled by the DReps who vote Yes meets a certain threshold of the total active voting stake)
  • the SPOs approve of the action (the stake controlled by the SPOs who vote Yes meets a certain threshold over the total delegated active stake for the epoch)

Warning As explained above, different stake distributions apply to DReps and SPOs.

A successful motion of no-confidence, election of a new constitutional committee, a constitutional change, or a hard-fork, delays ratification of all other governance actions until the first epoch after their enactment. This gives a new constitutional committee enough time to vote on current proposals, re-evaluate existing proposals with respect to a new constitution, and ensures that the in principle arbitrary semantic changes caused by enacting a hard-fork do not have unintended consequences in combination with other actions.

Requirements

The following table details the ratification requirements for each governance action scenario. The columns represent:

  • Governance action type<br/> The type of governance action. Note that the protocol parameter updates are grouped into four categories.

  • Constitutional committee (abbrev. CC)<br/> A value of ✓ indicates that the constitutional committee must approve this action.<br/> A value of - means that constitutional committee votes do not apply.

  • DReps<br/> The DRep vote threshold that must be met as a percentage of active voting stake.

  • SPOs<br/> The SPO vote threshold which must be met as a percentage of the stake held by all stake pools.<br/> A value of - means that SPO votes do not apply.

Governance action typeCCDRepsSPOs
1. Motion of no-confidence-$P_1$$Q_1$
2<sub>a</sub>. New committee/threshold (normal state)-$P_{2a}$$Q_{2a}$
2<sub>b</sub>. New committee/threshold (state of no-confidence)-$P_{2b}$$Q_{2b}$
3. Update to the Constitution or proposal policy$P_3$-
4. Hard-fork initiation$P_4$$Q_4$
5<sub>a</sub>. Protocol parameter changes, network group$P_{5a}$-
5<sub>b</sub>. Protocol parameter changes, economic group$P_{5b}$-
5<sub>c</sub>. Protocol parameter changes, technical group$P_{5c}$-
5<sub>d</sub>. Protocol parameter changes, governance group$P_{5d}$-
6. Treasury withdrawal$P_6$-
7. Info$100$$100$

Each of these thresholds is a governance parameter. There is one additional threshold, Q5, related to security relevant protocol parameters, which is explained below. The initial thresholds should be chosen by the Cardano community as a whole. The two thresholds for the Info action are set to 100% since setting it any lower would result in not being able to poll above the threshold.

Some parameters are relevant to security properties of the system. Any proposal attempting to change such a parameter requires an additional vote of the SPOs, with the threshold Q5.

The security relevant protocol parameters are:

  • maxBBSize
  • maxTxSize
  • maxBHSize
  • maxValSize
  • maxBlockExUnits
  • minFeeA
  • minFeeB
  • coinsPerUTxOByte
  • govActionDeposit
  • minFeeRefScriptsCoinsPerByte

Note It may make sense for some or all thresholds to be adaptive with respect to the Lovelace that is actively registered to vote. For example, a threshold could vary between 51% for a high level of registration and 75% for a low level registration. Moreover, the treasury threshold could also be adaptive, depending on the total Lovelace that is being withdrawn, or different thresholds could be set for different levels of withdrawal.

Note To achieve legitimacy, the minimum acceptable threshold should be no less than 50% of the delegated stake.

Restrictions

Apart from Treasury withdrawals and Infos, we include a mechanism for ensuring that governance actions of the same type do not accidentally clash with each other in an unexpected way.

Each governance action must include the governance action ID for the most recently enacted action of its given type. This means that two actions of the same type can be enacted at the same time, but they must be deliberately designed to do so.

Enactment

Actions that have been ratified in the current epoch are prioritized as follows for enactment:

  1. Motion of no-confidence
  2. New committee/threshold
  3. Update to the Constitution or proposal policy
  4. Hard Fork initiation
  5. Protocol parameter changes
  6. Treasury withdrawals
  7. Info

Note Enactment for Info actions is a null action, since they do not have any effect on the protocol.

Order of enactment

Governance actions are enacted in order of acceptance to the chain. This resolves conflicts where, e.g. there are two competing parameter changes.

Lifecycle

Governance actions are checked for ratification only on an epoch boundary. Once ratified, actions are staged for enactment.

All submitted governance actions will therefore either:

  1. be ratified, then enacted
  2. or expire after a number of epochs

In all of those cases, deposits are returned immediately.

All governance actions are enacted on the epoch boundary after their ratification.

Content

Every governance action will include the following:

  • a deposit amount (recorded since the amount of the deposit is an updatable protocol parameter)
  • a reward address to receive the deposit when it is repaid
  • an anchor for any metadata that is needed to justify the action
  • a hash digest value to prevent collisions with competing actions of the same type (as described earlier)
<!-- TODO: Provide a CBOR specification in the annexe for these new on-chain entities -->

In addition, each action will include some elements that are specific to its type:

Governance action typeAdditional data
1. Motion of no-confidenceNone
2. New committee/thresholdThe set of verification key hash digests (members to be removed), a map of verification key hash digests to epoch numbers (new members and their term limit), and a fraction (new threshold)
3. Update to the Constitution or proposal policyAn anchor to the Constitution and an optional script hash of the proposal policy
4. Hard-fork initiationThe new (greater) major protocol version
5. Protocol parameters changesThe changed parameters
6. Treasury withdrawalA map from stake credentials to a positive number of Lovelace
7. InfoNone

Note The new major protocol version must be precisely one greater than the current protocol version. Any two consecutive epochs will therefore either have the same major protocol version, or the later one will have a major protocol version that is one greater.

Note There can be no duplicate committee members - each pair of credentials in a committee must be unique.

Each governance action that is accepted on the chain will be assigned a unique identifier (a.k.a. the governance action ID), consisting of the transaction hash that created it and the index within the transaction body that points to it.

Protocol Parameter groups

We have grouped the protocol parameter changes by type, allowing different thresholds to be set for each group.

We are not, however, restricting each protocol parameter governance action to be contained within one group. In case where a governance action carries updates for multiple parameters from different groups, the maximum threshold of all the groups involved will apply to any given such governance action.

The network, economic and technical parameter groups collect existing protocol parameters that were introduced during the Shelley, Alonzo and Babbage eras. In addition, we introduce a new governance group that is specific to the new governance parameters that will be introduced by CIP-1694.

The network group consists of:

  • maximum block body size (maxBBSize)
  • maximum transaction size (maxTxSize)
  • maximum block header size (maxBHSize)
  • maximum size of a serialized asset value (maxValSize)
  • maximum script execution units in a single transaction (maxTxExUnits)
  • maximum script execution units in a single block (maxBlockExUnits)
  • maximum number of collateral inputs (maxCollateralInputs)

The economic group consists of:

  • minimum fee coefficient (minFeeA)
  • minimum fee constant (minFeeB)
  • delegation key Lovelace deposit (keyDeposit)
  • pool registration Lovelace deposit (poolDeposit)
  • monetary expansion (rho)
  • treasury expansion (tau)
  • minimum fixed rewards cut for pools (minPoolCost)
  • minimum Lovelace deposit per byte of serialized UTxO (coinsPerUTxOByte)
  • prices of Plutus execution units (prices)

The technical group consists of:

  • pool pledge influence (a0)
  • pool retirement maximum epoch (eMax)
  • desired number of pools (nOpt)
  • Plutus execution cost models (costModels)
  • proportion of collateral needed for scripts (collateralPercentage)

The governance group consists of all the new protocol parameters that are introduced in this CIP:

  • governance voting thresholds ($P_1$, $P_{2a}$, $P_{2b}$, $P_3$, $P_4$, $P_{5a}$, $P_{5b}$, $P_{5c}$, $P_{5d}$, $P_6$, $Q_1$, $Q_{2a}$, $Q_{2b}$, $Q_4$)
  • governance action maximum lifetime in epochs (govActionLifetime)
  • governance action deposit (govActionDeposit)
  • DRep deposit amount (drepDeposit)
  • DRep activity period in epochs (drepActivity)
  • minimal constitutional committee size (ccMinSize)
  • maximum term length (in epochs) for the constitutional committee members (ccMaxTermLength)
<!-- TODO: - Decide on the initial values for the new governance parameters - Decide on coherence conditions on the voting thresholds. For example, the threshold for a motion of no-confidence should arguably be higher than that of a minor treasury withdrawal. --> <!--------------------------- Governance Actions ------------------------> <!--------------------------- Votes ------------------------>

Votes

Each vote transaction consists of the following:

  • a governance action ID
  • a role - constitutional committee member, DRep, or SPO
  • a governance credential witness for the role
  • an optional anchor (as defined above) for information that is relevant to the vote
  • a 'Yes'/'No'/'Abstain' vote

For SPOs and DReps, the number of votes that are cast (whether 'Yes', 'No' or 'Abstain') is proportional to the Lovelace that is delegated to them at the point the action is checked for ratification. For constitututional committee members, each current committee member has one vote.

Warning 'Abstain' votes are not included in the "active voting stake".

Note that an explicit vote to abstain differs from abstaining from voting. Unregistered stake that did not vote behaves like an 'Abstain' vote, while registered stake that did not vote behaves like a 'No' vote. To avoid confusion, we will only use the word 'Abstain' from this point onward to mean an on-chain vote to abstain.

The governance credential witness will trigger the appropriate verifications in the ledger according to the existing UTxOW ledger rule (i.e. a signature check for verification keys, and a validator execution with a specific vote redeemer and new Plutus script purpose for scripts).

Votes can be cast multiple times for each governance action by a single credential. Correctly submitted votes override any older votes for the same credential and role. That is, the voter may change their position on any action if they choose. As soon as a governance action is ratified, voting ends and transactions containing further votes are invalid.

Governance state

When a governance action is successfully submitted to the chain, its progress will be tracked by the ledger state. In particular, the following will be tracked:

  • the governance action ID
  • the epoch that the action expires
  • the deposit amount
  • the rewards address that will receive the deposit when it is returned
  • the total 'Yes'/'No'/'Abstain' votes of the constitutional committee for this action
  • the total 'Yes'/'No'/'Abstain' votes of the DReps for this action
  • the total 'Yes'/'No'/'Abstain' votes of the SPOs for this action

Changes to the stake snapshot

Since the stake snapshot changes at each epoch boundary, a new tally must be calculated when each unratified governance action is checked for ratification. This means that an action could be enacted even though the DRep or SPO votes have not changed (since the vote delegation could have changed).

Definitions relating to voting stake

We define a number of new terms related to voting stake:

  • Lovelace contained in a transaction output is considered active for voting (that is, it forms the "active voting stake"):
    • It contains a registered stake credential.
    • The registered stake credential has delegated its voting rights to a DRep.
  • Relative to some percentage P, a DRep (SPO) vote threshold has been met if the sum of the relative stake that has been delegated to the DReps (SPOs) that vote Yes to a governance action is at least P.

Rationale

Role of the constitutional committee

At first sight, the constitutional committee may appear to be a special committee that has been granted extra power over DReps. However, because DReps can replace the constitutional committee at any time and DRep votes are also required to ratify every governance action, the constitutional committee has no more (and may, in fact, have less) power than the DReps. Given this, what role does the committee play, and why is it not superfluous? The answer is that the committee solves the bootstrapping problem of the new governance framework. Indeed, as soon as we pull the trigger and enable this framework to become active on-chain, then without a constitutional committee, there would rapidly need to be sufficient DReps, so that the system did not rely solely on SPO votes. We cannot yet predict how active the community will be in registering as DReps, nor how reactive other Ada holders will be regarding delegation of votes.

Thus, the constitutional committee comes into play to make sure that the system can transition from its current state into fully decentralized governance in due course. Furthermore, in the long run, the committee can play a mentoring and advisory role in the governance decisions by being a set of elected representatives who are put under the spotlight for their judgment and guidance in governance decisions. Above all, the committee is required at all times to adhere to the Constitution and to ratify proposals in accordance with the provisions of the Constitution.

Intentional Omission of Identity Verification

Note that this CIP does not mention any kind of identity validation or verification for the members of the constitutional committee or the DReps.

This is intentional.

We hope that the community will strongly consider only voting for and delegating to those DReps who provide something like a DID to identify themselves. However, enforcing identity verification is very difficult without some centralized oracle, which we consider to be a step in the wrong direction.

Reducing the power of entities with large amounts of Ada

Various mechanisms, such as quadratic voting, have been proposed to guard against entities with a large amount of influence. In a system based on "1 Lovelace, 1 vote", however, it is trivially easy to split stake into small amounts and undo the protections. Without an on-chain identity verification system we cannot adopt any such measures.

Piggybacking on stake pool stake distribution

The Cardano protocol is based on a Proof-of-Stake consensus mechanism, so using a stake-based governance approach is sensible. However, there are many ways that could be used to define how to record the stake distribution between participants. As a reminder, network addresses can currently contain two sets of credentials: one to identify who can unlock funds at an address (a.k.a. payment credentials) and one that can be delegated to a stake pool (a.k.a. delegation credentials).

Rather than defining a third set of credentials, we instead propose to re-use the existing delegation credentials, using a new on-chain certificate to determine the governance stake distribution. This implies that the set of DReps can (and likely will) differ from the set of SPOs, so creating balance. On the flip side, it means that the governance stake distribution suffers from the same shortcomings as that for block production: for example, wallet software providers must support multi-delegation schemes and must facilitate the partitioning of stake into sub-accounts should an Ada holder desire to delegate to multiple DReps, or an Ada holder must manually split their holding if their wallet does not support this.

However, this choice also limits future implementation effort for wallet providers and minimizes the effort that is needed for end-users to participate in the governance protocol. The latter is a sufficiently significant concern to justify the decision. By piggybacking on the existing structure, the system remains familiar to users and reasonably easy to set up. This maximizes both the chance of success of, and the rate of participation in, the governance framework.

Separation of Hard Fork Initiation from Standard Protocol Parameter Changes

In contrast to other protocol parameter updates, hard forks (or, more correctly, changes to the protocol's major version number) require much more attention. Indeed, while other protocol parameter changes can be performed without significant software changes, a hard fork assumes that a super-majority of the network has upgraded the Cardano node to support the new set of features that are introduced by the upgrade. This means that the timing of a hard fork event must be communicated well ahead of time to all Cardano users, and requires coordination between stake pool operators, wallet providers, DApp developers, and the node release team.

Hence, this proposal, unlike the Shelley scheme, promotes hard fork initiations as a standalone governance action, distinct from protocol parameter updates.

The purpose of the DReps

Nothing in this proposal limits SPOs from becoming DReps. Why do we have DReps at all? The answer is that SPOs are chosen purely for block production and not all SPOs will want to become DReps. Voters can choose to delegate their vote to DReps without needing to consider whether they are also a good block producer, and SPOs can choose to represent Ada holders or not.

Ratification Requirements Table

The requirements in the ratification requirement table are explained here. Most of the governance actions have the same kind of requirements: the constitutional committee and the DReps must reach a sufficient number of 'Yes' votes. This includes these actions:

  • New committee/threshold (normal state)
  • Update to the Constitution
  • Protocol parameter changes
  • Treasury withdrawal

Motion of no-confidence

A motion of no-confidence represents a lack of confidence by the Cardano community in the current constitutional committee, and hence the constitutional committee should not be included in this type of governance action. In this situation, the SPOs and the DReps are left to represent the will of the community.

New committee/threshold (state of no-confidence)

Similar to the motion of no-confidence, electing a constitutional committee depends on both the SPOs and the DReps to represent the will of the community.

The versatility of the info governance action

While not binding on chain, the Info governance action could be useful in an number of situations. These include:

  • ratifying a CIP
  • deciding on the genesis file for a new ledger era
  • recording initial feedback for future governance actions

Hard-Fork initiation

Regardless of any governance mechanism, SPO participation is needed for any hard fork since they must upgrade their node software. For this reason, we make their cooperation explicit in the hard fork initiation governance action, by always requiring their vote. The constitutional committee also votes, signaling the constitutionality of a hard fork. The DReps also vote, to represent the will of every stake holder.

New Metadata structures

The governance actions, the votes and the certificates and the Constitution use new metadata fields, in the form of URLs and integrity hashes (mirroring the metadata structure for stake pool registration). The metadata is used to provide context. Governance actions need to explain why the action is needed, what experts were consulted, etc. Since transaction size constraints should not limit this explanatory data, we use URLs instead.

This does, however, introduce new problems. If a URL does not resolve, what should be the expectation for voting on that action? Should we expect everyone to vote 'No'? Is this an attack vector against the governance system? In such a scenario, the hash pre-image could be communicated in other ways, but we should be prepared for the situation. Should there be a summary of the justification on chain?

Alternative: Use of transaction metadata

Instead of specific dedicated fields in the transaction format, we could instead use the existing transaction metadata field.

Governance-related metadata can be clearly identified by registering a CIP-10 metadata label. Within that, the structure of the metadata can be determined by this CIP (exact format TBD), using an index to map the vote or governance action ID to the corresponding metadata URL and hash.

This avoids the need to add additional fields to the transaction body, at the risk of making it easier for submitters to ignore. However, since the required metadata can be empty (or can point to a non-resolving URL), it is already easy for submitters to not provide metadata, and so it is unclear whether this makes the situation worse.

Note that transaction metadata is never stored in the ledger state, so it would be up to clients to pair the metadata with the actions and votes in this alternative, and would not be available as a ledger state query.

Controlling the number of active governance actions

Since governance actions are available for anyone to submit, we need some mechanism to prevent those individuals responsible for voting from becoming overwhelmed with a flood of proposals. A large deposit is one such mechanism, but this comes at the unfortunate cost of being a barrier for some people to submit an action. Note, however, that crowd-sourcing with a Plutus script is always an option to gather the deposit.

We could, alternatively, accept the possibility of a large number of actions active at any given time, and instead depend on off-chain socialization to guide voters' attention to those that merit it. In this scenario, the constitutional committee might choose to only consider proposals which have already garnered enough votes from the DReps.

No AVST

An earlier draft of this CIP included the notion of an "active voting stake threshold", or AVST. The purpose of AVST was to ensure the legitimacy of each vote, removing the possibility that, for example, 9 out of 10 Lovelace could decide the fate of millions of entities on Cardano. There are really two concerns here, which are worth separating.

The first concern is that of bootstrapping the system, i.e. reaching the initial moment when sufficient stake is registered to vote. The second concern is that the system could lose participation over time. One problem with the AVST is that it gives an incentive for SPOs to desire a low voting registration (since their votes then hold more weight). This is absolutely not a slight on the existing SPOs, but an issue with bad incentives.

We have chosen, therefore, to solve the two concerns differently. We solve the bootstrapping problem as described in the section on bootstrapping. We solve the long-term participation problem by not allowing reward withdrawals (after the bootstrap phase) unless the stake is delegated to a DRep (including the two special cases, namely 'Abstain' and 'No confidence').

Changelog

Changes post Longmont workshop (March 2023)

  • Thank the workshop attendees.
  • We have added Constitutional Committee terms.
  • Two new "pre-defined" DRep options: abstain and no confidence.
  • New "Info" governance action.
  • Use the most recent DRep stake distribution for ratification. This means that if ever your DRep votes how you do not like, you can immediately make yourself a DRep and vote how you want.
  • Escrow some ADA from the current treasury for potential future DRep incentives.
  • Remove the tiered treasury actions in favor of something adaptive (so the "yes" threshold would depend on:
    1. how much ada,
    2. how high the registered voting stake, and maybe
    3. how much ada is released every epoch
  • Split the protocol parameter updates into four groups: network, economic, technical, and governmental.
  • Most governmental actions can be enacted (upon ratification) right away. All but: protocol parameters and hard forks.
  • Remove "one action per type per epoch" restriction in favor of tracking the last action ID of each type, and including this in the action.
  • No AVST.
  • Bootstrap phase: Until X% of ADA is registered to vote or Y epochs have elapsed, only parameter changes and hard forks can happen. PP changes just need CC quorum, HFs need CC and SPOs. After the bootstrap phase, we put in place the incentive to keep low DReps, but this mechanism automatically relaxes.
  • New plutus script purpose for DReps.
  • Multiple treasury withdrawals in one epoch.
  • A section on the recursive problem of "how do we ratify this CIP".
  • Changes to the local state-query protocol.
  • New ideas, time permitting:
    • Weigh SPO stake vote by pledge somehow.
    • DReps can specify which other DRep gets their delegators in the event that they retire.
    • Reduced government action deposit if one member of the CC signs off on it (which presumably means it has gone through some process).
    • Include hash of (future) genesis configuration within HF proposal.

Changes post Edinburgh workshop (July 2023)

  • Add proposal policy, which can control what treasury withdrawals and protocol parameter changes are allowed.
  • Remove dropping of governance actions. The only effect this has is that in case a no confidence action passes, actions stay around. However, only new committee proposals that have been designed to build on top of that no confidence action can be enacted. If a new committee gets elected while some of those actions haven't expired, those actions can be ratified but the new committee has to approve them.
  • All governance actions are enacted one epoch after they are ratified.
  • Move post-bootstrapping restrictions into 'Other Ideas'.
  • Add a section on different deposit amounts to 'Other Ideas'.
  • Add a section for a minimum AVS to 'Other Ideas'.
  • Rename some protocol parameters.
  • Rename TALLY to GOV.
  • Turn the Constitution into an anchor.
  • Rework which anchors are required and which are optional.
  • Clean up various inconsistencies and leftovers from older versions.

Security-relevant changes and other fixes

  • Guard security-relevant changes behind SPO votes.
  • The system does not enter a state of no confidence with insufficient active CC members, the CC just becomes unable to act.
  • Clarify that CC members can use any kind of credential.

Path to Active

Acceptance Criteria

  • A new ledger era is enabled on the Cardano mainnet, which implements the above specification.

Implementation Plan

The features in this CIP require a hard fork.

This document describes an ambitious change to Cardano governance. We propose to implement the changes via one hard fork.

In the following sections, we give more details about the various implementation work items that have already been identified. In addition, the final section exposes a few open questions which will need to be finalized. We hope that those questions can be addressed through community workshops and discussions.

Ratification of this proposal

The ratification of this proposal is something of a circular problem: we need some form of governance framework in order to agree on what the final governance framework should be. As has been stated many times, CIPs are not authoritative, nor are they a governance mechanism. Rather, they describe technical solutions that have been deemed sound (from a technical standpoint) by community of experts.

CIP-1694 arguably goes beyond the usual scope of the CIP process and there is a strong desire to ratify this CIP through some process. However, that process is yet to be defined and it remains an open question. The final ratification process is likely to be a blend of various ideas, such as:

  • Gather opinions from community-held workshops, akin to the Colorado workshop of February-March 2023.
  • Exercise voting actions on a public testnet, with sufficient participation.
  • Poll the established SPOs.
  • Leverage Project Catalyst to gather inputs from the existing voting community (albeit small in terms of active stake).

Changes to the transaction body

  • New elements will be added to the transaction body, and existing update and MIR capabilities will be removed. In particular,

    The governance actions and votes will comprise two new transaction body fields.

  • Three new kinds of certificates will be added in addition to the existing ones:

    • DRep registration
    • DRep de-registration
    • Vote delegation

    And similarly, the current MIR and genesis certificates will be removed.

  • A new Voting purpose will be added to Plutus script contexts. This will provide, in particular, the vote to on-chain scripts.

Warning As usual, we will provide a CDDL specification for each of those changes.

Changes to the existing ledger rules

  • The PPUP transition rule will be rewritten and moved out of the UTxO rule and into the LEDGER rule as a new GOV rule.

    It will process and record the governance actions and votes.

  • The NEWEPOCH transition rule will be modified.

  • The MIR sub-rule will be removed.

  • A new RATIFY rule will be introduced to stage governance actions for enactment.

    It will ratify governance actions, and stage them for enactment in the current or next epoch, as appropriate.

  • A new ENACTMENT rule will be called immediately after the EPOCH rule. This rule will enact governance actions that have previously been ratified.

  • The EPOCH rule will no longer call the NEWPP sub-rule or compute whether the quorum is met on the PPUP state.

Changes to the local state-query protocol

The on-chain governance workload is large, but the off-chain workload for tools and applications will arguably be even larger. To build an effective governance ecosystem, the ledger will have to provide interfaces to various governance elements.

While votes and DReps (de)registrations are directly visible in blocks and will, therefore, be accessible via the existing local-chain-sync protocols; we will need to upgrade the local-state-query protocol to provide extra insights on information which are harder to infer from blocks (i.e. those that require maintaining a ledger state). New state queries should cover (at least):

  • Governance actions currently staged for enactment
  • Governance actions under ratification, with the total and percentage of yes stake, no stake and abstain stake
  • The current constitutional committee, and constitution hash digest

Bootstrapping Phase

We will need to be careful how we bootstrap this fledgling government. All the parties that are involved will need ample time to register themselves and to become familiar with the process.

Special provisions will apply in the initial bootstrap phase. Firstly, during the bootstrap phase, a vote from the constitutional committee is sufficient to change the protocol parameters. Secondly, during the bootstrap phase, a vote from the constitutional committee, together with a sufficient SPO vote, is sufficient to initiate a hard fork. No other actions are possible during the bootstrap phase.

The bootstrap phase ends when a given number of epochs has elapsed, as specified in the next ledger era configuration file. This is likely to be a number of months after the hard fork.

Moreover, there will be an interim Constitutional committee, also specified in the next ledger era configuration file, whose term limits will be set to expire when the bootstrap phase ends. The rotational schedule of the first non-bootstrap committee could be included in the constitution itself. Note, however, that since the constitutional committee never votes on new committees, it cannot actually enforce the rotation.

Other Ideas / Open Questions

Pledge-weighted SPO voting

The SPO vote could additionally be weighted by each SPO's pledge. This would provide a mechanism for allowing those with literal stake in the game to have a stronger vote. The weighting should be carefully chosen.

Automatic re-delegation of DReps

A DRep could optionally list another DRep credential in their registration certificate. Upon retirement, all of the DRep's delegations would be automatically transferred to the given DRep credential. If that DRep had already retired, the delegation would be transfer to the 'Abstain' DRep.

No DRep registration

Since the DRep registration does not perform any necessary functions, the certificates for (de-)registering DReps could be removed. This makes the democracy more liquid since it removes some bureaucracy and also removes the need for the DRep deposit, at the cost of moving the anchor that is part of the DRep registration certificate into the transaction metadata.

Reduced deposits for some government actions

The deposit that is attached to governance actions exists to prevent a flood of non-serious governance actions, each of which would require time and attention from the Cardano community. We could reduce this deposit for proposals which go through some agreed upon off-chain process. This would be marked on-chain by the endorsement of at least one constitutional committee member. The downside of this idea is that it gives more power to the constitutional committee.

Different deposit amounts for different governance actions

Multiple workshops for this CIP have proposed to introduce a different deposit amount for each type of governance action. It was not clear whether a majority was in favor of this idea, but this may be considered if it becomes clear that it is necessary.

Minimum active voting stake

As a further guarantee to ensure governance actions cannot be proposed right before a hard fork, be voted on by one DRep with a large amount of stake and be enacted immediately, there could be an additional requirement that a certain fixed absolute amount of stake needs to cast a 'Yes' vote on the action to be enacted.

This does not seem necessary in the current design, since the stake of all registered DReps behaves like a 'No' vote until they have actually cast a vote. This means that for this scenario to occur, the malicious actor needs at least to be in control of the fraction of DRep stake corresponding to the relevant threshold, at which point this might as well be considered a legitimate action.

Include hash of (future) genesis configuration within hard-fork proposal

Some hard-forks require new genesis configurations. This has been the case for the Shelley and Alonzo hard forks (but not Allegra, Mary, Vasil or Valentine), may be the case in the future. At the moment, this proposal doesn't state anything about such a genesis configuration: it is implicitly assumed to be an off-chain agreement. We could however, enforce that (the hash of) a specific genesis configuration is also captured within a hard-fork governance action.

Adaptive thresholds

As discussed above, it may make sense for some or all thresholds to be adaptive with respect to the Lovelace that is actively registered to vote, so that the system provides greater legitimacy when there is only a low level of active voting stake. The bootstrapping mechanism that is proposed above may subsume this, however, by ensuring that the governance system is activated only when a minimum level of stake has been delegated to DReps.

Renaming DReps / state of no-confidence?

It has been stated several times that "DReps" as presented here, might be confused with Project Catalst DReps. Similarly, some people have expressed confusion between the state of no-confidence, the motion of no-confidence and the no-confidence DReps.

We could imagine finding better terms for these concepts.

Rate-limiting treasury movements

Nothing prevents money being taken out of the treasury other than the proposed votes and voting thresholds. Given that the Cardano treasury is a quite fundamental component of its monetary policy, we could imagine enforcing (at the protocol level) the maximum amount that can removed from the treasury over any period of time.

Final safety measure, post bootstrapping

Many people have stated that they believe that the actual voting turnout will not be so large as to be a strain on the throughput of the system. We also believe that this is likely to be the case, but when the bootstrap phase ends we might put one final, temporary safety measure in place (this will also allow us to justify a low DRep deposit amount).

For values of $X$ and $Y$ that are still to be determined, as soon as the bootstrap phase has ended, when we calculate the DReps stake distribution for the next epoch boundary, we will consider only those DReps that are either in the top $X$-many DReps ranked by stake amount, or those DReps that have at least $Y$ Lovelace. Every epoch, the value of $X$ will increase and the value of $Y$ will decrease, so that eventually $X$ will be effectively infinite and $Y$ will be zero. Note that this is only an incentive, and nothing actually stops any DRep from casting their vote (though it will not be counted if it does not meet the requirements).

If the community decides at some point that there is indeed a problem with congestion, then a hard fork could be enacted that limits the number of DReps in a more restrictive way.

Reasonable numbers for the initial value of $X$ are probably 5,000-10,000. Reasonable numbers for the initial value of $Y$ are probably the total number of Lovelace divided by the initial value of $X$.

The mechanism should be set to relax at a rate where the restriction is completely eliminated after a period of six months to one year.

Copyright

This CIP is licensed under CC-BY-4.0

Footnotes

  1. A formal description of the current rules for governance actions is given in the Shelley ledger specification.

    • For protocol parameter changes (including hard forks), the PPUP transition rule (Figure 13) describes how protocol parameter updates are processed, and the NEWPP transition rule (Figure 43) describes how changes to protocol parameters are enacted.

    • For funds transfers, the DELEG transition rule (Figure 24) describes how MIR certificates are processed, and the MIR transition rule (Figure 55) describes how treasury and reserve movements are enacted.

    Note The capabilities of the MIR transition rule were expanded in the Alonzo ledger specification

  2. There are many varying definitions of the term "hard fork" in the blockchain industry. Hard forks typically refer to non-backwards compatible updates of a network. In Cardano, we formalize the definition slightly more by calling any upgrade that would lead to more blocks being validated a "hard fork" and force nodes to comply with the new protocol version, effectively obsoleting nodes that are unable to handle the upgrade.

Community Translations

Translations done through rewarded bounties at the Catalyst Swarm Bounty Board

Donations to Catalyst Swarm:Addr1qxhxg0mwzahfv8x4nr5s9zmffssxueqsnxxv282kz2c30nykg8fw8x99crukwyc7yftwfgxmhsu2xx0n8elfvj7mljlqm45kgs

Conversations

Join the conversation on Github

Leave a Comment

Overall I'm very impressed with and happy with the contents, structure, ideas, and work put into the draft CIP-1694. Personally I was considering some similar ideas for governance, however because this isn't my field of expertise my ideas were not nearly as comprehensive.

One feature of this CIP that I really like is that there is no mandatory hierarchical structure for how payouts must be made. This leaves funding the future community structure of the (members based organization, professional society, Catalyst startup incubator, whatever outcome of the Cardano constitutional process) entirely flexible. This flexibility is wise and is absolutely necessary for financial (fund/defund) checks-and-balances of future Cardano (organizations/ societies/ companies/ developers/ contractors/ ect).

view on Github

One feature of this CIP that I really like is that there is no mandatory hierarchical structure for how payouts must be made. This leaves funding the future community structure of the (members based organization, professional society, Catalyst startup incubator, whatever outcome of the Cardano constitutional process) entirely flexible. This flexibility is wise and is absolutely necessary for financial (fund/defund) checks-and-balances of future Cardano (organizations/ societies/ companies/ developers/ contractors/ ect).

Thank you, Michael. Yes, the CIP is deliberately foundational rather than prescribing any specific structure.

view on Github

thanks for all the great suggestions @michaelpj , I've just added a commit, "address comments 20221122", addressing a lot of it. In particular, I'm really glad that you suggested the rationale on the table values, as I found a problem. The AVST was not supposed to be ignored when the constitutional committee does not vote, it is required (which is stronger than diverting the responsibility to the SPOs). So now there is a new column in the table, and explanations.

I've added several section to the rationale.

I've left some TODO's, one for the potential other acceptance criterion and one to think more about the treasury voting thresholds (taking @michael-liesenfelt 's comments into account).

I removed the yes/no ratio remarks that were not correct.

I did not yet address any of the comments about the described implementation plan, I will probably need more help understanding those remarks.

view on Github

Hi @JaredCorduan et al,

@ltouro suggested that I review your proposal. I’m interested in learning about your CIP. Could you please give me some links where I can read about the background for the idea?

Specifically, I am interested in reading about your rationale for the model of government that you propose for Cardano. I began drafting a CIP myself that would involve a model of government based fundamentally on a decentralized autonomous organization (DAO). The draft is available at CIP-x?—I Gave at the Office. Comments are welcome at Cardano Governance #376.

I understand some of the challenges associated with creating a stable DAO. For example, see Waves founder: DAOs will never work without fixing governance. I believe that my CIP draft maintains a starting point capable of successfully overcoming such challenges.

I have a background in IT as a Technical Writer and Instructional Designer, with a Business Analysis foundation. My graduate research in clinical psychology focussed on investigating social networks within workplaces and organizations using electronic communications, and I hold a related US patent.

In response to the concerns expressed by @Kronoshus regarding doing work for free, I believe that such resentment should not be ignored. Have you considered seeking funding for developing the CIP through Project Catalyst? I would be interested in exploring such an avenue myself. I believe that the timing may be good to apply for the next round of funding, with community voting set to start sometime early in 2023, if I recall correctly. I believe that the Project Catalyst application essentially boils down to an estimate and a schedule, which would be important documents to prepare and maintain for a successful project anyway, in my experience.

Oliver

view on Github

Hi all,

I've just read the CIP-1694 and the comments in this issue. I have some thoughts about them:

  1. I read some comments above which I agree with. I feel that the name of the Constitutional Committee isn't accurate. It should be named something like Governance Committee or something like this.

  2. I was thinking about the point 1 and another idea comes to me. Maybe we need an initial Constitutional Committee which creates the constitution and has a grace period to govern with its rules. After this grace period, we would need to revalidate all the members and/or add new ones for the first "Governance Committee".

  3. I understand that we can remove members of the CC with an action proposal, but it requires someone to do actively an action. I'm not comfortable with this situation because this doesn't incentivizes the committee members to participate, and it might cause that they prefer to have a passive role. I think that the membership of the committee should be revalidated after some time.

I hope these points are useful, or at least they spark some debate.

Juan

view on Github

Is there a documented business case for CIP-1694? If so, could someone please post the link? I would like to get up to speed as quickly as possible.

If information is still being gathered, such as competitive analysis or benchmark studies to compare the strengths and weaknesses of CPI-1694? with those of Cardano's competitors, then I would like to suggest reviewing the PivX DAO (see also Why and How the PIVX DAO Works, for example).

view on Github

Thank you Oliver.

I have considered asking for funding yet I still would like some sort of official support by the community or IOG. There are many that do not see the point in creating legal framework and I would like to hear from them because I only ever hear from people that agree with me. If everyone agrees a need for law is necessary then I will go ahead with making a full manual for tribunals.

In addition to the need for punitive legal framework in a governance system, someone will also need to make administrative/business law for non-punitive governance actions such as all these nice ideas we love talking about. I am not very good at making legal code around that but a couple of lawyers have reached out to me for that. They just need to have official support from some entity too before writing the code.

If law is not created before the governance proposal is implemented, then there will be many issues in the future or people simply will not use the system, call it broken like what happened with Catalyst, and move on with their lives.

V/r,

Kevin Mohr

view on Github

In reference to Juan's 3rd point here, https://github.com/cardano-foundation/CIPs/pull/380#issuecomment-1327335051

He is right. There is no legal procedure to defend oneself if being removed from a committee, thus what incentive would anyone have to do anything once on the committee besides hold power.

V/r,

Kevin Mohr

view on Github

Thank you @Kronoshus I am going to spend time to read An On-Chain Decentralized Governance Mechanism for Voltaire in detail.

Oliver

view on Github

The CIP-50 analysis of actual state of Cardano network decentralization has taught one very powerful lesson so far: High leverage is bad.

Applying this lesson to social decentralization and governance it would be wise to limit the voting power of all SPO's to some leverage limit multiple of the SPO's pledge: L. This has a profound effect: there is an added social/governance motivation for pledge. Groups like Binance and Coinbase which do not pledge any ADA would have no voting power.

view on Github

On the topic of pledge and leverage, would it be possible to include time duration for pledge existence? The use of time duration for a pools pledge (i.e. 10 epochs) could prevent pools from updating their pledge to increase vote impact then remove the pledge to keep their ADA in a more liquid state.

view on Github
2. I was thinking about the point 1 and another idea comes to me. Maybe we need an initial Constitutional Committee which creates the constitution and has a grace period to govern with its rules. After this grace period, we would need to revalidate all the members and/or add new ones for the first "Governance Committee".

3. I understand that we can remove members of the CC with an action proposal, but it requires someone to do actively an action. I'm not comfortable with this situation because this doesn't incentivizes the committee members to participate, and it might cause that they prefer to have a passive role. I think that the membership of the committee should  be revalidated after some time.

yep, these are valid concerns. I think a forced election after the first Constitutional Committee is less controversial. If we forced a re-election at timed intervals, the worry is that progress grinds to a halt (but could be worthwhile anyway).

view on Github

Applying this lesson to social decentralization and governance it would be wise to limit the voting power of all SPO's to some leverage limit multiple of the SPO's pledge: L. This has a profound effect: there is an added social/governance motivation for pledge. Groups like Binance and Coinbase which do not pledge any ADA would have no voting power.

I think this is a very valid point, thank you @michael-liesenfelt . How do we reconcile this, however, with the fact that SPOs that do not wish for a hard fork can always just not upgrade their software? If they do that, as a collective, then the 'no' vote is basically determined by the longest chain, which ignores pledge.

view on Github

On the topic of pledge and leverage, would it be possible to include time duration for pledge existence? The use of time duration for a pools pledge (i.e. 10 epochs) could prevent pools from updating their pledge to increase vote impact then remove the pledge to keep their ADA in a more liquid state.

That's very interesting. Perhaps that could be a separate CIP.

view on Github

I’m interested in learning about your CIP. Could you please give me some links where I can read about the background for the idea?

Is there a documented business case for CIP-1694? If so, could someone please post the link? I would like to get up to speed as quickly as possible.

@paradoxicalsphere - @CharlesHoskinson has made a lot of great content about governance on his youtube channel. you might enjoy these (and can probably find many others like it):

view on Github

@michael-liesenfelt : limit the voting power of all SPO's to some leverage limit multiple of the SPO's pledge: L.

@JaredCorduan : How do we reconcile this, however, with the fact that SPOs that do not wish for a hard fork can always just not upgrade their software?

Naturally the result of CIP-50 with a leverage limit L would have to be hard-fork adopted and actively applied to block allocation schedules and reward incentives before it was also used for governance.

view on Github

Hi @JaredCorduan et al, Hi @CharlesHoskinson,

I would like to offer a positive and constructive response to the following list of concerns raised in the past few days in response to CIP-1694?:


@jmagan (posted on November 25, 2022)

Maybe we need an initial Constitutional Committee which creates the constitution and has a grace period to govern with its rules. After this grace period, we would need to revalidate all the members and/or add new ones for the first "Governance Committee".

...we can remove members of the CC with an action proposal, but it requires someone to do actively an action. I'm not comfortable with this situation because this doesn't incentivizes the committee members to participate, and it might cause that they prefer to have a passive role.


@michaelpj (posted on November 26, 2022)

...the logic of which properties you get for different vote and thresholds is quite complex and could stand to be spelled out extremely explicitly.


@GGAlanSmithee (posted on November 26, 2022)

If anyone can vote (represent themselves) what is even the point with having representatives?

...another issue with other systems of representation (a democracy, for example) is that representatives get equal voting power on all issues that are presented before them (which would be all issues in the system described here, as I understand it). I see this as a bit problematic, since having a large stake of ADA does not automatically equates to having the right know how and understanding to make all types of decision.

...the system incentivizes active participation, which actually makes the prior point even worse. Representatives will be incentiviced to vote on issues they know little or nothing about. You could say that in such a case they should vote blank, but if so, why even include them in the vote at all? I think having some form of committee system would make sense here.

This text doesn't describe what kind of forum (if any) there will be for the decisionmakers to get together, vet ideas, make their cases, argue points, etc.

If there is no formal procedure/structure, as described in the prior point, so that conversations can happen openly, I fear that closed-room meetings will take their place (which is probably the case now to a large degree).


@GGAlanSmithee (posted on November 26, 2022)

"I thought the whole point of DReps was that most votes should be delegated..." I think this is one of the most imporant issues in this text, that it seems to contradict itself in that it wants to incentivise dReps, but I think it will be hard for meaningful representation to happen if everyone represents themselves (for reasons previously stated).

I do not like the idea of randomized subsets of the dReps, since that will really leave the door open for missrepreserntation imo (read earlier comments about this). I would be much more comfortable with dReps on specific classes of issues (read committees). In that case, the total set of representatives/votes/votes will not be as large for any given action/vote (since only a subset of dReps will vote on any class of issues - the ones they a representatives of).


@michael-liesenfelt (posted on November 27, 2022)

...it would be wise to limit the voting power of all SPO's to some leverage limit multiple of the SPO's pledge: L. This has a profound effect: there is an added social/governance motivation for pledge.


@Balance-Analytics (posted on November 27, 2022)

On the topic of pledge and leverage, would it be possible to include time duration for pledge existence? The use of time duration for a pools pledge (i.e. 10 epochs) could prevent pools from updating their pledge to increase vote impact then remove the pledge to keep their ADA in a more liquid state.


@GGAlanSmithee (posted on November 26, 2022)

"Requiring a large deposit when registering oneself as a DRep."... I'm not sure this is a great idea. I think it's a good idea in the case of SPOs, since your stake is directly involved in the method of securing the network, but in the case of dReps, that will be voting on issues regarding the future changes to the network, other factors, such as expertise in a given area is IMO more important.


@ia-davidpichler (posted on November 26, 2022)

...the US constitution doesn't lay out Congress customs and proceedings in it, just what they are responsible for.


@kronoshus (posted on November 26, 2022)

If law is not created before the governance proposal is implemented, then there will be many issues in the future or people simply will not use the system, call it broken like what happened with Catalyst, and move on with their lives.


@kronoshus (posted on November 26, 2022)

There is no legal procedure to defend oneself if being removed from a committee, thus what incentive would anyone have to do anything once on the committee besides hold power.


In general, concerns seem to focus on how to manage cliques that may develop within a governance model. The concerns are justified. At the most general level, a clique is a sub-set of a network in which the actors are more closely and intensely tied to one another than they are to other members of the network. While cliques may form as a natural tendency of human behaviour, cliques must be both manageable and managed to preserve a society or network as a whole. Changing too much at once in the Cardano ecosystem would increase risk, and may potentially lead to unforeseen—even catastrophic—consequences. A Sybil attack is an extreme example of clique behavior.

As @ia-davidpichler seems to confirm in passing, CIP-1694? is based on a model of government fashioned after the United States. Cardano is a global ecosystem not necessarily bound by geopolitics.

Cardano infrastructure that exists today has successfully shepherded the development and growth of Cardano as a top-ten project within the Web3 space for the past five or more years. I would suggest that the concerns listed above may be mitigated by leveraging global infrastructures already in place within the Cardano ecosystem.

Also, arguably, decentralized autonomous organizations (DAOs) are the future of governance.

Engaging organizations responsible for the creation of Cardano and respective employees as governance ambassadors leverages existing standards of professional conduct, working relationships, legal contracts, agreements, processes and arrangements already in place with individuals and groups already proven over time to be effective, with motivation to continue preserving and garnering the interests of the wider Cardano community.

Individual employees able to engage with SPOs in the form of offering delegations empowers employees to incentivize stake pools, stake pool operators and developers to create and maintain projects that are not only in the interests of the project owners, but are also useful to the Cardano ecosystem as a whole.

Incentivizing SPOs offers a means to incentivize prospective delegators indirectly as well, in order to increase overall market share and investment in Cardano over time.

Cliques that may form between individuals and teams of employees are manageable by the employer at the middle and upper management levels.

No one would be forced to be interested in the good graces of an employee DAO. By introducing an employee DAO that shares a balance of power with respective employers, with the support of the community, a punitive system of governance for the Cardano community is not required any more than has been required over the past five or more years.

At this point, as a sidebar in parallel to the current thread, I would like to invite debate, thoughts and questions on the potential benefits of a DAO governance model for Cardano based on the draft proposal It Takes a Village. Please feel free to leave a comment or create an Issue.

view on Github

Fair enough!


From: Jared Corduan @.> Sent: Tuesday, 29 November 2022 9:32 PM To: cardano-foundation/CIPs @.> Cc: Paul Morris @.>; Mention @.> Subject: Re: [cardano-foundation/CIPs] CIP-1694? | A proposal for entering the Voltaire phase (PR #380)

@JaredCorduan commented on this pull request.


In CIP-1694/README.mdhttps://github.com/cardano-foundation/CIPs/pull/380#discussion_r1034757533:

+* The PPUP transition rule will be rewritten and moved out of the UTxO rule and into the LEDGER rule as a new TALLY rule. +

  • It will process the governance actions and the votes, ratify them, and stage governance actions for enactment in the current or next epoch, as appropriate.

+* The NEWEPOCH transition rule will be modified. +* The MIR sub-rule will be removed. +* A new ENACTMENT rule will be called immediately after the EPOCH rule. This rule will enact governance actions that have previously been ratified. +* The EPOCH rule will no longer call the NEWPP sub-rule or compute whether the quorum is met on the PPUP state.

+#### More on DRep incentives + +The DReps arguably need to be compensated for their work.

+The corresponding incentive mechanisms need to be specified, with the funds probably coming from the per-epoch treasury allocation. +Performance constraints will also need to be considered since it would be problematic if millions of DReps were expected to vote on each governance action. Some incentive options to ensure a manageable number of DReps include:

i would hope that the requirement to vote is rare

Some of the actions we expect to be rare, such as changing the constitution.

Some of the actions we expect to be common, such as treasury withdrawals for things like Catalyst.

Some of the actions could really go either way, there are valid arguments that some of the protocol parameters should be more adaptive.

— Reply to this email directly, view it on GitHubhttps://github.com/cardano-foundation/CIPs/pull/380#discussion_r1034757533, or unsubscribehttps://github.com/notifications/unsubscribe-auth/A4MSBKKJ6YN6HZXT4GBZ2CLWKYAX3ANCNFSM6AAAAAASD5YWY4. You are receiving this because you were mentioned.Message ID: @.***>

view on Github

To encourage community involvement while also keeping the discussion here on GitHub confined to the technical proposal and its documentation, we've resolved at the CIP Editors' Meeting today to create a Discord channel for more liberal discussion: #voltaire-governance (server invite)

Voltaire entry & governance discussions - For observations and feedback around the pending CIP-1694 (https://github.com/cardano-foundation/CIPs/pull/380) and other CIPs which may relate to the technical aspects of Cardano on-chain governance.

Please note the distinction between governance as applied to blockchain systems (impartial systems of assigning influence and control by consensus) and government established by conventional legal or political systems. To keep discussion technically relevant, a list of "on" topics will be posted here when available.

Resolutions from & summaries of the discussion here, if relevant to the CIP process (https://github.com/cardano-foundation/CIPs/blob/master/CIP-0001), should be posted back to the corresponding GitHub public CIP discussion thread. The Editors are not obligated to summarise nor add any comments from other users to the relevant GitHub PR discussion threads.

Note this follows suit with the existing Discord group created for https://github.com/cardano-foundation/CIPs/pull/242 - but also that there is also a Governance discussion emerging here (which may be additionally useful to participants who can't use Discord): https://app.element.io/#/room/!nrkKgEbuxqnXktPqun:matrix.org

cc @JaredCorduan @michael-liesenfelt @KtorZ

(p.s. edited Mon 5 Dec 2022 15:45:05 UTC with information for "rebooted" Discord channel)

view on Github

Hi,

Further to my detailed comment on November 28, CIP 1694? seems to focus on leveraging financial stake in Cardano while specifically seeking to avoid or even prevent fiduciary responsibility. Fiduciary responsibility refers to a relationship in which one party (the fiduciary) is responsible for looking after the best interests of another party (the beneficiary). Fiduciary responsibility is a duty of loyalty and impartiality in placing the interests of a corporation, organization or individual first, not allowing decision making to be tainted by self-interest or self-dealing.

I do not believe that a governance model for Cardano can work without fiduciary obligation. The draft CIP It Takes a Village, for example, seeks to propose a model of government for Cardano that does not aim to introduce a systemic denial or avoidance of fiduciary responsibility into the Cardano ecosystem.

view on Github

I do not believe that a governance model for Cardano can work without fiduciary obligation. The draft CIP it Takes a Village, for example, seeks to propose a model of government for Cardano that does not aim to introduce a systemic denial or avoidance of fiduciary responsibility into the Cardano ecosystem.

The specification section of that CIP looks to be a list of questions, not a concrete proposal: https://github.com/paradoxicalsphere/cardano-improvement-proposals/blob/7ebe042ca104eb15c679ebab16148c065d1639f0/CIP-x/README.md#specification

view on Github

Hi @JaredCorduan

Yes, true, it's a starting point awaiting significant input from others who see the potential of the idea.

Further discussion is at #voltaire-governance (server invite) Your thoughts and comments would be more than welcome. I'm open to questions and constructive criticism on how to best develop the idea. I don't necessarily see the work that you're doing here as somehow mutually exclusive of my draft, so far. I don't see why the two proposals could not co-exist, potentially. You have a great deal of skill and talent here. I hope that you may value my input as well.

view on Github

@paradoxicalsphere : [...] somehow mutually exclusive of my draft, so far. I don't see why the two proposals could not co-exist, potentially.

https://discord.com/channels/971785110770831360/1047472328566657084/1048148685311184976 @KtorZ : There's a reason why CIPs are on Github and are purposely geared towards developers / software engineers. CIPs offer a way to discussion technical evolutions of the network. They aren't about how IO, CF or Emurgo manage their respective entities. If there are suggestions about how the CF should manage their funds and what their internal policies should be then CIPs are certainly not the right place to discuss that.

This is also true of this channel which is meant to discuss CIP-1694 primarily, and more broadly, what on-chain mechanisms can be put in place to support Cardano's governance.

So please, I'll ask folks here (mainly @paradoxicalsphere) to stop using this channel to discuss matters that are clearly out of scope of the CIP process. Otherwise, we'll just close this and invite you to have this conversation elsewhere. There's also no point submitting such a CIP because, as I said, this is completely out of the scope of the CIP process.

view on Github

Hi,

My reason for participating in the current mega-thread is encouragement to do so from https://github.com/cardano-foundation/CIPs/issues/376#issuecomment-1322688823 and a commitment to following the CIP process.

view on Github

Applying this lesson to social decentralization and governance it would be wise to limit the voting power of all SPO's to some leverage limit multiple of the SPO's pledge: L. This has a profound effect: there is an added social/governance motivation for pledge. Groups like Binance and Coinbase which do not pledge any ADA would have no voting power.

I think this is a very valid point, thank you @michael-liesenfelt . How do we reconcile this, however, with the fact that SPOs that do not wish for a hard fork can always just not upgrade their software? If they do that, as a collective, then the 'no' vote is basically determined by the longest chain, which ignores pledge.

Need to allow for the continual fragmentation of groups. Within SPO's you need to have a mechanism that allows them to split from the main vote and give their vote elsewhere. This is assuming you have a yes or no proposal system rather than one that allows fragmentation of yes or no options.

Idk how to reply to these things so forgive me if I did things wrong but wanted to make that point.

view on Github

I saw an interesting video by army of spies about chat.openai.com. I was inspired by the platforms outcome when asked to write a 4 paragraph academic essay comparing and contrasting the theories of nationalism of Benedit Anderson and Ernest Geller. In 10 seconds a very decent essay popped out.

I think the huge legacy of human endeavour to today contains all the wisdom to construct a very inspiring Constitution.

If this AI was asked to list the top 12 points for Human prosperity from the Zoroastrian Avesta, The Hindu Ramayana and Mahabharata, The Buddhist Tipitaka,, The Bible, The Koran The Tora etc, plus as many Legal rights and Constitutions of the world, US , Magna Carta etc

Reinventing the wheel is not required. AI's impartial unbiased, non sectarian and very fast results might give us something very balanced and valuable framework to draw upon.


From: Jared Corduan @.> Sent: Saturday, December 3, 2022 12:23:59 AM To: cardano-foundation/CIPs @.> Cc: Paul Morris @.>; Mention @.> Subject: Re: [cardano-foundation/CIPs] CIP-1694? | A proposal for entering the Voltaire phase (PR #380)

@JaredCorduan commented on this pull request.


In CIP-1694/README.mdhttps://github.com/cardano-foundation/CIPs/pull/380#discussion_r1038312060:

  • Otherwise, SPO vote endorsement is required. The :x: symbol indicates that the AVST will be ignored, and only the DRep and SPO votes will be considered regardless of the AVST.

+* SPOs<br/>

  • The SPO vote threshold which must be met as a percentage of the stake held by all stake pools. The SPO vote is only considered if the AVST threshold is :x: or the AVST is below the AVST threshold.

+| Governance Action Type | Constitutional Committee | DReps | AVST | SPOs | +| --- | :---: | --- | --- | --- | +| 1. Motion of no-confidence | :x: | $P_1$ | :x: | $R_1$ | +| 2(a). New Committee/quorum (normal state) | :heavy_check_mark: | $P_{2a}$ | $Q_{2a}$ | $R_{2a}$ | +| 2(b). New Committee/quorum (state of no-confidence)| :x: | $P_{2b}$ | :x: | $R_{2b}$ | +| 3. Update to the Constitution | :heavy_check_mark: | $P_3$ | $Q_3$ | $R_3$ | +| 4. Hard-Fork initiation | :heavy_check_mark: | $P_4$ | :x: | $R_4$ | +| 5. Protocol parameter changes | :heavy_check_mark: | $P_5$ | $Q_5$ | $R_5$ | +| 6(a). Treasury withdrawal, $[T_0, T_1)$ | :heavy_check_mark: | $P_{6a}$ | $Q_{6a}$ | $R_{6a}$ | +| 6(b). Treasury withdrawal, $[T_1, T_2)$ | :heavy_check_mark: | $P_{6b}$ | $Q_{6b}$ | $R_{6b}$ | +| 6(c). Treasury withdrawal, $[T_2, T_3)$ | :heavy_check_mark: | $P_{6c}$ | $Q_{6c}$ | $R_{6c}$ |

I have not yet added anything quite as prescriptive as what you are suggesting, but made a note of the topic in general:

https://input-output-rnd.slack.com/archives/GJGPC1QA3/p1669973606029659?thread_ts=1669973559.536239&cid=GJGPC1QA3

There are a few interesting things to still think about with respect to this action, and they might have interactions.

— Reply to this email directly, view it on GitHubhttps://github.com/cardano-foundation/CIPs/pull/380#discussion_r1038312060, or unsubscribehttps://github.com/notifications/unsubscribe-auth/A4MSBKP7AOLRDOXCWAZLW2DWLIPB7ANCNFSM6AAAAAASD5YWY4. You are receiving this because you were mentioned.Message ID: @.***>

view on Github

DReps is a role in Project Catalyst already with hundreds of people signed up. I fear that using the same term for this CIP will cause a fair amount of confusion. Is it possible to use a different name so we're not overloading DRep to represent two different roles?

view on Github

Hi @xeeban,

Please also consider a governance-related CIP draft at an earlier stage of development having far fewer problems at https://change.paradoxicalsphere.com/cip

view on Github

DReps is a role in Project Catalyst already with hundreds of people signed up. I fear that using the same term for this CIP will cause a fair amount of confusion. Is it possible to use a different name so we're not overloading DRep to represent two different roles?

This is the same role I believe? It is not using the same name for 2 different roles right?

view on Github