Welcome to SanchoNet - your gateway to Cardano's governance future!

SanchoNet is not an incentivized testnet and no real ada is rewarded for participation.

SanchoNet is the testnet for rolling out groundbreaking governance features for the Cardano blockchain, aligning with the comprehensive CIP-1694 specifications. SanchoNet stands apart from other testnets; it's a vibrant, inclusive, and community-driven platform. Every community member is invited to join SanchoNet and actively contribute to shaping Cardano's governance future.

As SanchoNet advances in its journey of implementation and feature rollout, the community is encouraged to embrace specific roles crucial for testing and refining the governance mechanisms:

1. **Testnet ada holders**: As a testnet ada holder, your role is paramount. You can engage in crafting and submitting governance actions, and your insights will be invaluable to ensure that the governance system upholds the highest standards of security and efficiency.

2. **Stake pool operators** (SPOs): SPOs are the backbone of any blockchain network, and on SanchoNet, it's no different. As an SPO, you can take charge and run the testnet network with diligence and integrity and of course, you can influence Barataria's future voting on relevant actions. Your feedback will be invaluable.

3. **Delegate representatives** (DReps): DReps are the voice of the broader community. As a representative, your role involves participating in voting on governance actions. You can consider the collective interests of the community as you engage in these important decisions.

** SanchoNet is under construction **
SanchoNet is all about developing and testing the technical components and processes required to action governance for Cardano within CIP-1694. It informs and engages the Cardano community on Voltaire on-chain governance activities currently underway.

To fully utilize the on-chain components as they are designed for ultimate use on mainnet, a significant program of off-chain elements (eg committees, informational tools, etc) will also need to be delivered, subject to a separate complimentary roadmap and timeline.

As such, SanchoNet will follow an independent development trajectory scoped from a technical, rather than final, governance perspective. SanchoNet will encapsulate the various actions and use cases that SPOs, DReps, and other users will undertake within typical usage situations as the wider governance capabilities are rolled out.

Therefore, not all SanchoNet functionality will operate initially as intended (for example, within constitutional actions), and will be subject to change and iteration during the course of development.

SanchoNet is more than just a testnet, it is a playground of opportunities. Within this space, the community can collaboratively create a governance system that is robust, decentralized, and truly community-driven. Your involvement, dedication, and passion will be the driving force behind SanchoNet's success.

**SanchoNet feature rollout**
The rollout of Sanchonet features will be phased in line with the technical development of CIP-1694:

![](https://media.discordapp.net/attachments/1095620786674466857/1281538809212702731/image.png?ex=66dc1585&is=66dac405&hm=24211f07827c07d8910674e8ef0eb48041b9818b49abfc1c6b507af63ad398cd&=&format=webp&quality=lossless&width=710&height=614)

SanchoNet

SanchoNet GovTool
![](https://sancho.network/assets/images/sanchonet-govtool-header-99e5e6bd2379a38b5ad6617b1baa1a0c.png)

**What is the SanchoNet GovTool?**
The SanchoNet GovTool enables ada holders to experience some of the governance features described in [CIP-1694](https://www.1694.io/) and to test governance features in SanchoNet through a guided and straightforward experience. The SanchoNet GovTool is currently open for beta testing and can be accessed at [sanchogov.tools](https://sanchogov.tools/).

**What is the Voltaire GovTool?**
The Voltaire GovTool, with the SanchoNet GovTool serving as its testnet version, will empower ada holders to register as delegate representatives (DReps), delegate voting power to DReps, and review and vote on governance actions. Governance tooling is owned and maintained by the community. With community approval, Intersect, through its committees and working groups, will play an important role in hosting and maintaining these governance tools. Through active community involvement, the aim is to create the initial foundation layer together with different builders in the community. These governance tools will support the entire process, encompassing both off-chain and on-chain aspects. As a whole, they will facilitate the implementation of the governance described in CIP-1694 and its adoption. Once this foundational layer is in place, the community will have the opportunity to enhance these governance tools. They will be able to achieve this by maintaining and improving existing features and pillars, creating new features, or establishing entirely new areas either independently or with support from awards and grants facilitated by Intersect. With the freedom to test and refine Cardano’s next era of governance principles under one central apparatus, the GovTool helps the Cardano community forge a future governance framework that represents the community’s best democratic interests.

**How to participate in the beta testing?**
The Voltaire GovTool will be one of the first tools to allow ada holders to experience the CIP-1694 governance on Cardano. The current version of this tool has been developed using initial feedback from the community and following what's described in CIP-1694. It's now important that the community tests this tool and provides valuable insights to further refine it and make it ready for future product use.

Check the [beta testing to-do list](https://docs.sanchogov.tools/about/sanchonet-govtool-testing) Check the [prerequisites to start](https://docs.sanchogov.tools/how-to-use-the-govtool/prerequsites) Check the [quick/start guide](https://docs.sanchogov.tools/how-to-use-the-govtool/getting-started)

**Related guides and resources**
[SanchoNet GovTool guides](https://docs.sanchogov.tools/) General governance guides Cardano governance page overview GovTool overview

SanchoNet GovTool

Getting started

The selection of the name 'SanchoNet' draws inspiration from the intricate and multifaceted character of Sancho Panza, Don Quixote’s companion in Miguel de Cervantes’ literary classic. In the narrative, Sancho's transformation from a humble farmer to a wise governor and loyal friend mirrors virtues that align with the principles steering the evolution and governance of this network.

Sancho's growth throughout the novel represents a synthesis of realism and idealism. He starts with a practical, down-to-earth perspective but gradually appreciates and even embraces the nobility in Don Quixote's vision of chivalry. His transformation culminates in the episode of governing the fictional 'Island of Barataria,' where his innate wisdom and common sense guide him in delivering fair and wise judgments.

Sancho's capability to harmonize pragmatic realities with lofty ideals mirrors the essence of SanchoNet. Much like Sancho, the mission of SanchoNet is to cultivate a system that remains grounded in reality while guided by visionary principles. The ultimate goal? To establish a platform where every voice holds significance, embracing inclusivity and pragmatic wisdom in governance.

The choice of 'SanchoNet' also mirrors the character's transformative journey, echoing the broader themes of growth, self-assurance, and integrity that resonate throughout 'Don Quixote.' The parallel between Sancho and the chivalric code, his self-discovery, and his courage to embrace the extraordinary within himself symbolizes Cardano's aspiration to innovate, empower individuals, and attain greatness.

Moreover, the intimate relationship between Don Quixote and Sancho, characterized by friendship, mutual influence, and a complex balance between dreams and reality, parallels the collaborative spirit that SanchoNet aims to cultivate within the Cardano community. This partnership transcends mere transactional engagements and evolves into a collective journey toward a more equitable, visionary, and improved ecosystem.

Why SanchoNet?

Alonso Quijano, the man who would become Don Quixote, begins as an ordinary gentleman from the La Mancha region. He's known to be deeply fixated on books of chivalry. This eventually causes him to lose touch with reality. He decides to resurrect the age of chivalry, renaming himself 'Don Quixote de la Mancha.' This signifies the onset of his transformation, both in regard to his identity and how the world views him.

In the beginning, Don Quixote's idealism is unrestrained and almost childlike. He perceives the world through a fantastical lens, turning windmills into giants and common inns into castles. His commitment to chivalric codes and virtues is unwavering, albeit frequently misdirected. His notions of honor, justice, and love are drawn from his readings, not real-life encounters. This often leads him into absurd and humorous predicaments. Don Quixote's idealism often materializes as a stubborn refusal to see the world as it truly is, exemplified by his renowned attack on windmills that he misidentifies as giants.

As the novel unfolds, Don Quixote's character gradually evolves. The initial portrayal of a madman driven by unattainable dreams slowly gives way to a more nuanced and intricate individual. Despite his delusions, nobility resides in his ideals that begin to resonate with those around him. His faith in his knightly mission affects those he encounters, and even those who initially dismiss him as mad come to recognize the sincerity and purity of his beliefs.

While his squire, Sancho Panza, serves as a foil and grounding influence, Don Quixote also influences Sancho. The relationship between the two characters deepens, as each leaves their mark on the other. Over time, Don Quixote's lofty ideals gradually meld with a more pragmatic grasp of reality, while Sancho starts to appreciate the merits of his master's chivalric worldview.

As the story concludes, Don Quixote's character experiences a remarkable evolution. His adventures have led to personal growth, deepening wisdom, and a more profound understanding of himself and the world around him. The sharp contrast between idealism and realism has dissolved, giving rise to a more harmonized and human portrayal.

The culmination of this evolution arrives with the tragic realization of his madness and his decision to forsake his knightly persona, reverting back to Alonso Quijano. This final transformation is tinged with sadness, as it signifies the loss of the beautiful ideals that drove him, but it also represents a return to sanity and a reconciliation with the real world.

The character of Don Quixote is multi-layered, showcasing a complex evolution. Starting from the naive and delusional Quijano, progressing to the quixotic yet profoundly honorable Don Quixote, and culminating in the wiser and more self-aware man by the narrative's closure, Cervantes skillfully constructs a character that encapsulates the human conflict between idealism and reality. His journey resonates because it mirrors the quest for meaning, virtue, and self-understanding, making Don Quixote a timeless and universal figure in literature.

Don Quixote

Sancho Panza, initially depicted as a simple farmer, evolves remarkably throughout the story of 'Don Quixote.' His evolution begins upon becoming the squire of Don Quixote, motivated by the promise of material wealth and the opportunity to govern an island. Though Sancho starts as a counterpoint to Don Quixote's lofty idealism, embodying pragmatism and practicality, his persona gradually deepens, becoming more nuanced and complex.

As Sancho accompanies Don Quixote on his chivalric endeavors, he finds himself drawn into the world of ideals and imagination. Though never entirely abandoning his earthy wisdom, Sancho gradually recognizes the nobility within his master's vision. He starts to see beyond the surface of things, recognizing the deeper values of justice, honor, and compassion that underpin Don Quixote's seemingly mad pursuits.

The most profound change in Sancho's character comes during his time as the governor of the fictional 'Island of Barataria.' Initially intended as a jest, this episode evolves into a profound experience for Sancho. Faced with the complexities of leadership and governance, Sancho rises to the challenge. He applies his simple wisdom and innate understanding of human nature to solve intricate problems. Instead of becoming confused or overwhelmed, Sancho demonstrates a remarkable ability to govern justly and wisely.

The experience of governing Barataria has a lasting impact on Sancho, reinforcing his self-assurance and deepening his understanding of leadership and responsibility. It also further aligns him with Don Quixote's chivalric code, showing him that ideals and practicality can coexist and that ordinary people are capable of extraordinary things.

Sancho's relationship with Don Quixote continues to evolve, moving from servitude to genuine friendship. He becomes a true companion, sharing Don Quixote's dreams and defending them against the skepticism of others. By the end of the story, Sancho's character grows into a synthesis of realism and idealism, embodying the wisdom of the common man and the nobility of the knight-errant.

Sancho's evolution is a testament to the profound impact of friendship, idealism, and personal growth. His journey reflects the novel's rich exploration of human nature, presenting a timeless portrayal of an ordinary man achieving greatness through wisdom, integrity, and the courage to embrace the extraordinary within himself.

Sancho Panza

Barataria plays a unique and significant role in 'Don Quixote.' While existing only in fiction, its symbolism and the events that unfold within its imagined boundaries contribute meaningfully to the novel's exploration of leadership, governance, idealism, and reality.

In the story, Barataria is a fictional island promised to Sancho Panza, Don Quixote's loyal squire, as a reward for his devoted service. The pledge of ruling Barataria fuels Sancho's dreams and expectations. When a duke and duchess, entertained by Don Quixote and Sancho, decide to actualize this promise, they execute an elaborate prank by appointing Sancho as the governor of the nonexistent island.

The Barataria episode offers an opportunity to explore Sancho's character, unveiling his practical wisdom and inherent common sense. Despite the absurd situations aimed at testing and mocking him, Sancho governs with dignity, simplicity, and intelligence. His judgments and decrees are marked by a natural grasp of justice and human nature. Instead of becoming a fool in a comedic setting, Sancho turns Barataria into a stage for showcasing his authentic wisdom and leadership.

Barataria also serves as a mirror to the broader themes of the novel. Just as Don Quixote's idealism often clashes with the harsh realities of the world, Sancho's time in Barataria illustrates the tension between appearance and substance, dream and reality, folly and wisdom. It is a microcosm of the novel's intricate dance between the world as it is and the world as it could be.

Barataria serves as a link between the lofty ideals of chivalry embodied by Don Quixote and the grounded realism of Sancho. Within this imaginary island, the dreams of both characters converge, and their contrasts find a harmonious resolution.

In Western literature, the Barataria episode has transcended its origin to become a symbol of leadership that is wise, compassionate, and unpretentious. It stands as a reminder that true wisdom often resides in simplicity and that leadership can be found in the most unlikely places.

Barataria

**The Constitution**
The Constitution is an off-chain document with its hash registered on-chain. A provisional Constitution, containing essential provisions and safeguards necessary for the implementation of CIP-1694, has been published [here](https://constitution.gov.tools/en/interim-constitution). This provisional document is intended as a temporary measure. The final Constitution, which will require ratification by Ada holders, is expected to be approved by late 2024 or early 2025.

In addition, the Constitution is supplemented by a set of "Guardrails" to ensure the blockchain operates securely and sustainably. These guardrails are designed to prevent unexpected issues with the operation of the Cardano Blockchain. They aim to guide the selection of sensible parameter settings and mitigate potential problems related to security, performance, or functionality. Some of these guardrails are automatable and will be enforced via an on-chain script or built-in ledger rules.

**The Guardrails Script**
The Constitution is accompanied by a guardrails script. At any given time, there can only be one guardrails script, and its hash is also registered on-chain. The guardrails script enforces limits on protocol parameter changes and treasury withdrawals. This script is executed whenever a governance action attempts to change protocol parameters or make a treasury withdrawal. If the proposal adheres to the guardrails, it is accepted on-chain and can be considered by the governance bodies: the Constitutional Committee, DReps, and SPOs. Conversely, if the proposed change exceeds the guardrails, the action is deemed unconstitutional upon submission, and the transaction is rejected, reducing the risk of introducing undesirable changes to the protocol parameters.

**Constitutional Committee**
The Constitutional Committee is a group of individuals or entities, each associated with a pair of Ed25519 credentials or a script, collectively responsible for safeguarding the integrity of the constitution within the Cardano blockchain ecosystem.

The Constitutional Committee operates based on a social contract with the network's actors, focusing solely on voting for actions that align with the constitution. This ensures the upholding of the fundamental principles and values of the blockchain.

It's important to note that the Constitutional Committee has the authority to reject certain governance actions by voting 'no.' However, committee members should exercise this power judiciously, using it only when actions clearly conflict with the constitution.

As the guardian of the blockchain's integrity, the Constitutional Committee ensures that the network operates in harmony with its established principles. Through responsible decision-making and adherence to the constitution, the committee contributes to the sustainable and prosperous future of the blockchain ecosystem.

**Becoming a constitutional committee member**
Becoming a member of the constitutional committee involves off-chain procedures. The detailed process to join will be outlined in the upcoming weeks. Similar to how SPOs manage their cold/KES keys, committee members will utilize a cold/hot key setup. Hence, developing a solid understanding of the generation and secure management of these keys becomes crucial for those aspiring to join the committee.

In general, the constitutional committee member will need to:

1. Run a node
2. Request funds from the faucet
3. Generate cold/hot credentials (keys or scripts)
4. Generate their corresponding key hash or script hash.
5. Be elected on a governance action.
6. Once elected, create a corresponding cold -> hot authorization certificate and submit it on-chain
7. Review active governance actions
8. Engage in discussions with other constitutional committee members to assess the constitutionality of governance actions
9. Cast votes
10. Include anchors (URL/hash) in their votes.

Moreover, the committee members might be required to perform specific tests, such as issuing a new hot key and authorizing it, resigning from committee members, or voting on new committee members.

Detailed tutorials will be provided upon the launch of associated features. These tutorials will offer step-by-step guidance to ensure a smooth and effortless walkthrough of the process.

Constitutional committee

Stake pool operators are not only responsible for block production and network maintenance; they also have a role in the governance of the system. Stake pool operators can vote on motions of no confidence, electing new constitutional committee members, initiating hardforks, and making changes to security and relevant protocol parameters.

**Becoming an SPO**
Becoming an SPO is critical to support SanchoNet. The process is straightforward, follow the tutorials below:

1. Download the [latest node](https://github.com/IntersectMBO/cardano-node/releases/)
2. Run the node
3. Request funds from the faucet
4. Register a stake pool
5. Request delegation from the faucet

Stake pool operators (SPOs)

A DRep serves as the community's spokesperson, actively participating in voting on governance actions and advocating for the community's collective interests.

**Becoming a DRep**
As Cardano prepares for the Conway era, community participation becomes vital for its success. A meaningful way to contribute is by becoming a DRep and playing a key role in shaping Cardano's future.

DReps hold significant responsibilities in the governance process, voting on important system updates. Approval depends on the governance action type and requires a majority vote from the corresponding governance bodies (SPOs, the constitutional committee, and DReps).

As a DRep, you'll have the power to vote 'yes,' 'no,' or 'abstain' on governance actions proposing changes to protocol parameters. Your vote represents the ada holders' collective voice, making your role crucial in Cardano's decentralized decision-making.

To become a DRep, follow these steps:

1. Download the latest version of [cardano-node](https://github.com/IntersectMBO/cardano-node/releases)
2. Run the node
3. Request funds from the faucet
4. Register as a DRep with an on-chain registration certificate
5. Initially, on SanchoNet, use tools like Discord to identify governance actions requiring your attention and vote
6. Engage in discussions with other DReps to assess the merits of active governance actions
7. Cast your votes using Cardano CLI or other voting tools as they become available in the community
8. When submitting your votes, include reasoning for your vote and an anchor (URL and hash).

Stay tuned for comprehensive tutorials that will be provided upon the release of new features. You might be also asked to conduct specific tests from participants on SanchoNet, highlighting the importance of your active involvement.

Delegate representatives (DReps)

A SanchoNet developer is an individual skilled in blockchain technology and programming, with a passion for contributing to the evolution of Cardano's governance future.

**Develop on SanchoNet**
To interact with SanchoNet as a developer, you will need to:

1. Download the latest version of [cardano-node] (https://github.com/IntersectMBO/cardano-node/releases)
2. Run the node
3. Request funds from the faucet
4. Build a cool tool to integrate with SanchoNet
5. Publish it to the community.

**Community tooling**

**Wallets**

Wallets are websites or applications that convert a mnemonic into a user-friendly interface for sending and receiving ada. Below is a list of all the wallets currently available on SanchoNet:

**Explorers**

Explorers allow you to visualize blockchain data. Some are web-based, while others are generic APIs. Below is a list of the current explorers available on SanchoNet:

**Voting centers**

Voting centers enable interaction with the chain for viewing and voting on specific proposals. They can also integrate with wallets to facilitate delegation to DReps and submission of transactions to wallets.

Developers

Roles

[CIP-1694](https://cips.cardano.org/cip/CIP-1694) describes seven types of governance actions.

![](https://media.discordapp.net/attachments/1095620786674466857/1281544384780963850/image.png?ex=66dc1ab7&is=66dac937&hm=f50dba97a7735695fd7111f1784f8697e7b3691cfcf2d465d9c36692eabac4c2&=&format=webp&quality=lossless&width=819&height=573)

Each type of governance action represents a distinct feature within cardano-node and cardano-cli. As such, they will be rolled out in phases, coinciding with the integration of each feature.

**Governance Action Enactment Process**
Any ada holder can submit a governance action. Once on chain, specific governance groups need to vote on the action depending on its type. The following table details the ratification requirements for each governance action scenario. The columns represent:

- **Governance action type**
The type of governance action. Note that the protocol parameter updates are grouped into four categories.

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

- **DReps**
The DRep vote threshold that must be met as a percentage of active voting stake.

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

![](https://media.discordapp.net/attachments/1095620786674466857/1281545696167596114/image.png?ex=66dc1bef&is=66daca6f&hm=a607776a75b9a2bc321d7a146555809de9abfa451d0679ad7ee482c09acb504f&=&format=webp&quality=lossless&width=697&height=614)

Each of these thresholds is a governance parameter. There is one additional threshold, `Q5`, related to security relevant protocol parameters:

The security relevant protocol parameters are:

- `maxBlockBodySize`
- `maxTxSize`
- `maxBlockHeaderSize`
- `maxValueSize`
- `maxBlockExecutionUnits`
- `txFeePerByte`
- `txFeeFixed`
- `utxoCostPerByte`
- `govActionDeposit`
- `minFeeRefScriptCostPerByte`

To get ratified, a governance action needs to accumulate enough votes according to the specified thresholds. A governance action **expires** if it does not receive enough votes during its governance action lifetime.

Ratified governance actions are automatically **enacted** at the epoch boundary following their ratification.

The only exception is when a "Motion of No Confidence" is enacted prior to the enactment of other actions. In that case, the ratified but not yet enacted actions are not enacted. Instead, these actions are put back for voting for the remainder of their lifetime. If a new committee is elected before these actions expire, they can still be ratified, but the new committee must approve them.

![](https://media.discordapp.net/attachments/1095620786674466857/1281546811332497440/image.png?ex=66dc1cf9&is=66dacb79&hm=2546330229ab6cab209d4606a046f56af04b6236097e2a8f24ffa5508a24fc54&=&format=webp&quality=lossless&width=819&height=380)


Check out the Tutorials and Voting on governance actions to learn how to create and vote on governance actions.

SanchoNet governance actions

Governance actions

**SanchoNet faucet**

**To request funds from the faucet:**

1. Choose whether you want to request funds or a stake delegation
2. Fill in your details
3. Tick the recaptcha box
4. Click 'Submit'.

![](https://media.discordapp.net/attachments/1095620786674466857/1281548950897430591/image.png?ex=66dc1ef7&is=66dacd77&hm=55ffa151e080927c5dc9129e55dc11af3fea1faf89d88364e46cd05f98c1db2a&=&format=webp&quality=lossless&width=819&height=506)


When you have finished using your test tokens,
please return them to the faucet at the following address: addr_test1vz0ua2vyk7r4vufmpqh5v44awg8xff26hxlwyrt3uc67maqtql3kl

Faucet

**How to compile the guardrail script from source**
To compile the current version of the guardrail script yourself, you first have to clone the plutus repository

```
git clone https://github.com/IntersectMBO/plutus.git
cd plutus
```

Next we check out the version 1.31.0.0 of plutus and enter a nix development shell via

```
git checkout 1.31.0.0
nix develop
```

We then create a file `cabal.project.local` to override some dependencies as a hotfix (there is a circular dependency otherwise).

```
cat <<EOF > cabal.project.local
allow-newer: *:plutus-ledger-api
allow-newer: *:prettyprinter-configurable
EOF
```

Next, we open in a text editor the file `cardano-constitution/cardano-constitution.cabal` and delete line 134 that reads `buildable: False` via

`sed -i '134d' cardano-constitution/cardano-constitution.cabal`

Next, we can build the script via

```
cabal update
cabal run cardano-constitution:create-json-envelope -- guardrail.plutus
```

You can get the hash of this just compiled script via, for example

`cardano-cli transaction policyid --script-file guardrail.plutus`

And compare it to the one currently defined [here](https://book.world.dev.cardano.org/environments/mainnet/conway-genesis.json).

Compile the guardrail script

**Download or build cardano-node and cardano-cli binaries:**

- The latest version for SanchoNet is **9.1.0.** [See releases](https://github.com/IntersectMBO/cardano-node/releases).

**Get configuration files**

```
wget https://book.world.dev.cardano.org/environments/sanchonet/config.json
wget https://book.world.dev.cardano.org/environments/sanchonet/topology.json
wget https://book.world.dev.cardano.org/environments/sanchonet/byron-genesis.json
wget https://book.world.dev.cardano.org/environments/sanchonet/shelley-genesis.json
wget https://book.world.dev.cardano.org/environments/sanchonet/alonzo-genesis.json
wget https://book.world.dev.cardano.org/environments/sanchonet/conway-genesis.json
```


**Run the node**

```
cardano-node run --topology topology.json \
--database-path db \
--socket-path node.socket \
--port 3001 \
--config config.json
```

**Need help?**

For a step-by-step tutorial on how to build and run a node please visit [Cardano node course | Building and running the node.](https://cardano-course.gitbook.io/cardano-course/handbook/module-1-build-and-run-the-node/building-the-node)

Start a SanchoNet node

To align the tutorials, examples, and also third-party tooling, you can find a suggested file naming convention/schema related to the Conway and Voltaire eras in this document.

The schemas can be extended with a `*.` prefix if needed. For example:

- Suggested file name: `drep.skey`
- Extended with a prefix: `myname.drep.skey`

The naming convention is a work in progress. Please revisit this page regularly to check if any new or modified schemas have been selected.

**Constitution files**
Below is a list of currently used files related to the constitution's text-content/action/vote.

**Text/content**

`constitution.txt / *.constitution.txt` constitution in cleartext utf-8

**Action**

`constitution.action / *.constitution.action` for action file content in JSON

Example content:

```
{
    "type": "Governance proposal",
    "description": "",
    "cborHex": "841a000f4240581c1b7a61b...36a56ff490a4af6"
}
```

**Vote**

`constitution.vote / *.constitution.vote` for the vote ballot in JSON

Example content:

```
{
    "type": "Governance vote",
    "description": "",
    "cborHex": "8482582064e7cad9b3ece...1e235709ffa691001f6"
}
```

**SanchoNet delegate representatives (DReps) files**
Below is a list of currently used files related to SanchoNet DRep usage.

**Signing key**
Generated as a normal ed25519 key or derived from path `1852'/1815'/acc'/3/idx' drep.skey / *.drep.skey` for the SanchoNet DRep secret-key JSON (see example content below)

Example content:

```
{
    "type": "DRepSigningKey_ed25519",
    "description": "Delegate Representative Signing Key",
    "cborHex": "00000"
}
{
    "type": "DRepExtendedSigningKey_ed25519_bip32",
    "description": "Delegate Representative Signing Key",
    "cborHex": "5840d84f8646463b03accf....da82c5dba3b1e4aa0df20b7"
}
```

The keys derived from hardware wallets will have the keyword 'Hardware' in the description field, such as: 'Hardware Delegate Representative Signing Key'.

**Verification key**

`drep.vkey / *.drep.vkey` for the SanchoNet DRep verification-key JSON (see example content below)

Example content:

```
{
    "type": "DRepVerificationKey_ed25519",
    "description": "Delegate Representative Verification Key",
    "cborHex": "00000"
}
{
    "type": "DRepExtendedVerificationKey_ed25519_bip32",
    "description": "Delegate Representative Verification Key",
    "cborHex": "5820fd6b3cda64cf11f9b91ea3c88dffed906bc872f1e24566d68637c718788638d9"
}
```

The keys derived from hardware wallets will have the keyword 'Hardware' in the description field, such as: `Hardware Delegate Representative Verification Key`

**Identification file (ID)**

`drep.id / *.drep.id` for the DRep ID in bech format `drep1...`

Example content:

`drep12dggdndq3hhjzszukw5k5sulsesjux780s39h087s0p9vk6ylra`

**Registration certificate**

`drep-reg.cert / *.drep-reg.cert` for the registration certificate JSON

Example content:

```
{
    "type": "CertificateConway",
    "description": "DRep Registration Certificate",
    "cborHex": "00000000"
}
```

**Retirement certificate**

`drep-ret.cert / *.drep-ret.cert` for the de-registration/retirement certificate JSON

Example content:

```
{
    "type": "CertificateConway",
    "description": "DRep Retirement Certificate",
    "cborHex": "00000000"
}
```

**Vote delegation certificate**

`vote-deleg.cert / *.vote-deleg.cert` for the vote delegation certificate JSON

Example content:

```
{
    "type": "CertificateConway",
    "description": "Vote Delegation Certificate",
    "cborHex": "83098200581cc827e7d1fb57cf12662203612fe1f0bb3578574b16f90f4a78cd355c8200581c44924d8233e23a4eda97ba2ce0a336d6152171e70960396b4903eb8a"
}
```


**Constitution committee files**

Below is a list of currently used files related to the constitution committee member usage.

**Signing key (cold)**

`cc-cold.skey / *.cc-cold.skey` for the cold constitutional committee member secret-key JSON

**Signing key (hot)**

`cc-hot.skey / *.cc-hot.skey` for the hot constitutional committee member secret-key JSON

**Verification key (cold)**
`cc-cold.vkey / *.cc-cold.vkey` for the cold constitutional committee member verification-key JSON

**Verification key (hot)**
`cc-hot.vkey / *.cc-hot.vkey` for the hot constitutional committee member verification-key JSON

File naming convention/schema


First, generate a payment key pair and a stake key pair. Then, use the payment verification key and the stake verification key to build an address that can be used to receive funds from the faucet.

The payment keys control the funds, while the stake keys control the participation in the protocol: delegating stake to a pool and delegating votes to a delegate representative.

**Pre-requisites**

- cardano-cli installed

**Generate key pairs**

1. Generate payment keys:

```
cardano-cli conway address key-gen \
--verification-key-file payment.vkey \
--signing-key-file payment.skey
```

2. Generate stake keys:

```
cardano-cli conway stake-address key-gen \
--verification-key-file stake.vkey \
--signing-key-file stake.skey
```

**Build the address**

3. Build your address:

```
cardano-cli conway address build \
--payment-verification-key-file payment.vkey \
--stake-verification-key-file stake.vkey \
--out-file payment.addr \
--testnet-magic 4
```

**Get funds from the faucet**

4. Use your address on the faucet to get SanchoNet testnet tokens.

Generate keys and address

To take part on the SanchoNet consensus protocol, we need to submit a stake address registration certificate to the chain. This allows to delegate stake to a SanchoNet stake pool and votes to a SanchoNet delegate representative (DRep).

**Pre-requisites**

- Stake key pair
- Payment key pair
- Address with funds
- A SanchoNet node

**Generate the registration certificate**

1. Register the stake address you previously created by generating a registration certificate:

```
cardano-cli conway stake-address registration-certificate \
--stake-verification-key-file stake.vkey \
--key-reg-deposit-amt $(cardano-cli conway query gov-state --testnet-magic 4 | jq .currentPParams.stakeAddressDeposit) \
--out-file registration.cert
```


**Submit the certificate to the chain**

2. Build, sign and submit the transaction.

- **Build** the transaction:

```
cardano-cli conway transaction build \
--testnet-magic 4 \
--witness-override 2 \
--tx-in $(cardano-cli query utxo --address $(cat payment.addr) --testnet-magic 4 --out-file  /dev/stdout | jq -r 'keys[0]') \
--change-address $(cat payment.addr) \
--certificate-file registration.cert \
--out-file tx.raw
```


- **Sign** the transaction:

```
cardano-cli conway transaction sign \
--tx-body-file tx.raw \
--signing-key-file payment.skey \
--signing-key-file stake.skey \
--testnet-magic 4 \
--out-file tx.signed
```

- **Submit** the transaction:

```
cardano-cli conway transaction submit \
--testnet-magic 4 \
--tx-file tx.signed
```

Stake address registration certificate

**WARNING:** This tutorial is simplified and deliberately excludes secure key handling which is essential for other testnets and mainnet. For a comprehensive tutorial, see the [Cardano course](https://cardano-course.gitbook.io/cardano-course) where you can access video lessons and a more detailed instruction handbook.

**Prerequisites**

Before you start, ensure that you have:

1. A running node: see the tutorial
2. Created keys and addresses: see the tutorial
3. Requested funds from the faucet

**Set up a relay node**

Setting up a stake pool on SanchoNet involves configuring a block producer node and at least one relay node. The relay node plays a crucial role in propagating the blocks forged by your block-producing node, as well as fetching blocks from other stake pools and serving them to your block producer. In this structure, the block producer communicates solely with your relay node, which in turn interfaces with the rest of the network. This ensures a streamlined communication process and helps to secure your block producer.

The typical configuration of the stake pool should resemble the following:

![](https://sancho.network/assets/images/bpandrelay-3ee2a947193e9d780be6e81d068c14b7.png)

To set up your relay node, carry out the following steps:

1. **Install the Cardano node and the Cardano CLI** on your relay node.

2. **Configure the firewall for incoming connections**: set up the firewall to accept incoming connections on the specific port that you'll be using for the Cardano node. This allows other nodes, including your block producer, to communicate with your relay.

3. **Configure the firewall for outgoing connections**: enable the firewall to allow outgoing connections. This configuration ensures that your relay node can contact other relay nodes in the network as well as your block producer node.

4. **Run the node with P2P topology**: start your node using the P2P topology setting.


```
{
   "localRoots":[
      {
         "accessPoints":[],
         "advertise":false,
         "valency":2
      }
   ],
   "publicRoots":[
      {
         "accessPoints":[
            {
               "address":"sanchonet-node.world.dev.cardano.org",
               "port":30004
            }
         ],
         "advertise":false
      }
   ],
   "useLedgerAfterSlot":1000000
}
```

**Set up a block producer**

Setting up your block producer involves similar steps, but there are a few differences in the configuration:

1. **Install the Cardano node and the Cardano CLI** on your block producer node.

2. **Configure the firewall for incoming connections**: set up the firewall to accept incoming connections **only from your relay node** on the specific port that you'll be using for the Cardano node. This ensures that only your relay node can communicate with your block producer.

3. **Configure the firewall for outgoing connections**: enable the firewall to allow outgoing connections, preferably, **only to your own relay's IP and port**.

4. **Run the node with P2P topology**: start your node using the P2P topology configuration. This time, replace **"address":"x.x.x.x"** and **"port":3000** with the actual IP address and the port of your **own relay node**. Note that the block producer does not connect to `sanchonet-node.world.dev.cardano.org` and we avoid using ledger peers by setting `"useLedgerAfterSlot¨`to `-1`


```
{
   "localRoots":[
      {
         "accessPoints":[
            {
               "address":"x.x.x.x",
               "port":3000
            }
         ],
         "advertise":false,
         "valency":2
      }
   ],
   "publicRoots":[
      {
         "accessPoints":[
         ],
         "advertise":false
      }
   ],
   "useLedgerAfterSlot":-1
}
```

**Install jq and set the node socket path**

1. Install [jq](https://jqlang.github.io/jq/), a tool that will assist in parsing the UTXOs for transactions:

`sudo apt-get install jq -y`

2. Set the `CARDANO_NODE_SOCKET_PATH` variable to the path of `node.socket` that you identified when starting the node:

`export CARDANO_NODE_SOCKET_PATH=~/node.socket`

**Register the stake address**

3. Register the stake address you previously created by generating a registration certificate:

```
cardano-cli conway stake-address registration-certificate \
--stake-verification-key-file stake.vkey \
--key-reg-deposit-amt $(cardano-cli conway query gov-state --testnet-magic 4 | jq .currentPParams.stakeAddressDeposit) \
--out-file registration.cert
```


4. Create a transaction to submit the stake key registration certificate to the chain. Creating a transaction using the CLI always involves a three-step process: BUILDING, SIGNING, AND SUBMITTING the transaction.

- **Build** the transaction:

```
cardano-cli conway transaction build \
--testnet-magic 4 \
--witness-override 2 \
--tx-in $(cardano-cli query utxo --address $(cat payment.addr) --testnet-magic 4 --out-file  /dev/stdout | jq -r 'keys[0]') \
--change-address $(cat payment.addr) \
--certificate-file registration.cert \
--out-file tx.raw
```


- **Sign** the transaction:

```
cardano-cli conway transaction sign \
--tx-body-file tx.raw \
--signing-key-file payment.skey \
--signing-key-file stake.skey \
--testnet-magic 4 \
--out-file tx.signed
```

- **Submit** the transaction:

```
cardano-cli conway transaction submit \
--testnet-magic 4 \
--tx-file tx.signed
```

**Generate keys for the stake pool**

5. Generate cold keys and the operational certificate for your pool:

```
cardano-cli conway node key-gen \
--cold-verification-key-file cold.vkey \
--cold-signing-key-file cold.skey \
--operational-certificate-issue-counter-file opcert.counter
```

6. Generate the key-evolving-signature (KES) keys:

```
cardano-cli conway node key-gen-KES \
--verification-key-file kes.vkey \
--signing-key-file kes.skey
```

7. Generate VRF keys:

```
cardano-cli conway node key-gen-VRF \
--verification-key-file vrf.vkey \
--signing-key-file vrf.skey
```

**Generate the registration and delegation certificates for the pool**

8. Create your stake pool registration certificate:

```
cardano-cli conway stake-pool registration-certificate \
--cold-verification-key-file cold.vkey \
--vrf-verification-key-file vrf.vkey \
--pool-pledge 9000000000 \
--pool-cost 340000000 \
--pool-margin 0.05 \
--pool-reward-account-verification-key-file stake.vkey \
--pool-owner-stake-verification-key-file stake.vkey \
--testnet-magic 4 \
--pool-relay-ipv4 <RELAY NODE PUBLIC IP> \
--pool-relay-port <RELAY NODE PORT> \
--out-file pool-registration.cert
```

9. Create a stake delegation certificate:

```
cardano-cli conway stake-address stake-delegation-certificate \
--stake-verification-key-file stake.vkey \
--cold-verification-key-file cold.vkey \
--out-file delegation.cert
```

**Submit the certificates in a transaction**

10. Build, sign and submit the transaction

- Build:

```
cardano-cli conway transaction build \
--testnet-magic 4 \
--witness-override 3 \
--tx-in $(cardano-cli query utxo --address $(cat payment.addr) --testnet-magic 4 --out-file  /dev/stdout | jq -r 'keys[0]') \
--change-address $(cat payment.addr) \
--certificate-file pool-registration.cert \
--certificate-file delegation.cert \
--out-file tx.raw
```


- Sign:

```
cardano-cli conway transaction sign \
--tx-body-file tx.raw \
--signing-key-file payment.skey \
--signing-key-file cold.skey \
--signing-key-file stake.skey \
--testnet-magic 4 \
--out-file tx.signed
```

- Submit:

```
cardano-cli conway transaction submit \
--testnet-magic 4 \
--tx-file tx.signed
```

11. Get your pool ID, you will need to get a delegation from the faucet:

```
cardano-cli conway stake-pool id \
--cold-verification-key-file cold.vkey \
--output-format bech32 \
--out-file pool.id
```

**Starting the node as a block-producer**

12. Generate your operational certificate:

```
slotsPerKESPeriod=$(cat shelley-genesis.json | jq -r '.slotsPerKESPeriod')
slotNo=$(cardano-cli query tip --testnet-magic 4 | jq -r '.slot')
kesPeriod=$((${slotNo} / ${slotsPerKESPeriod}))
cardano-cli conway node issue-op-cert --kes-verification-key-file kes.vkey --cold-signing-key-file cold.skey --operational-certificate-issue-counter-file opcert.counter --kes-period ${kesPeriod} --out-file opcert.cert
```


13. Request a stake delegation from the faucet. Note that although the delegation will ocurr immediately, you will need two more epochs for your Block producer to start creating blocks. This due to the stake snashopt mechanism.

14. Restart your node using your pool credentials:

```
cardano-node run --topology topology.json \
--database-path db \
--socket-path node.socket \
--shelley-kes-key kes.skey \
--shelley-vrf-key vrf.skey \
--shelley-operational-certificate opcert.cert \
--port 3001 \
--config config.json
```

15. Your stake pool will take part of the stake snapshot on the next epoch boundary. After that, you will be able to query the stake delegated to your pool:

```
cardano-cli conway query stake-snapshot \
--testnet-magic 4 \
--stake-pool-id <pool_id>
```

16. After two epochs (2 days in SanchoNet) your stake pool should start producing blocks, the easiest way to verify it is to `grep` your node logs

`grep -e TraceForgedBlock`

Register a stake pool

**Pre-requisites**

- Payment address with funds
- A SanchoNet node

**Generate SanchoNet DRep keys and an ID**

1. Generate a DRep key pair:

```
cardano-cli conway governance drep key-gen \
--verification-key-file drep.vkey \
--signing-key-file drep.skey
```

```
{
    "type": "DRepSigningKey_ed25519",
    "description": "Delegate Representative Signing Key",
    "cborHex": "5820eba7053fdc9cb3b8aacf142d3d4ad575bb48fb92f4082d81605ac8e2ccfead5d"
}
```


```
{
    "type": "DRepVerificationKey_ed25519",
    "description": "Delegate Representative Verification Key",
    "cborHex": "5820c19e0e939609531cfd04dcfa5bf1a5f3e245aa88e163759341aba296af34cc7e"
}
```


2. Generate a SanchoNet DRep ID:

```
cardano-cli conway governance drep id \
--drep-verification-key-file drep.vkey \
--out-file drep.id
```

`drep124w9k5ml25kcshqet8r3g2pwk6kqdhj79thg2rphf5u5urve0an`

**Generate the registration certificate**

1. Create a SanchoNet DRep registration certificate

There are three ways to generate the certificate:

- Using the drep.vkey file:

```
cardano-cli conway governance drep registration-certificate \
--drep-verification-key-file drep.vkey \
--key-reg-deposit-amt $(cardano-cli conway query gov-state --testnet-magic 4 | jq -r .currentPParams.dRepDeposit) \
--out-file drep-register.cert
```


- Using the DRep verification key:

```
cardano-cli conway governance drep registration-certificate \
--drep-verification-key "$(cat drep.vkey | jq -r .cborHex | cut -c 5-)" \
--key-reg-deposit-amt $(cardano-cli conway query gov-state --testnet-magic 4 | jq -r .currentPParams.dRepDeposit) \
--out-file drep-register.cert
```


- Using the DRep ID:

```
cardano-cli conway governance drep registration-certificate \
--drep-key-hash $(cat drep.id) \
--key-reg-deposit-amt $(cardano-cli conway query gov-state --testnet-magic 4 | jq -r .currentPParams.dRepDeposit) \
--out-file drep-register.cert
```


Any of the above methods produces drep-register.cert, which contains:

```
{
    "type": "CertificateShelley",
    "description": "DRep Key Registration Certificate",
    "cborHex": "84108200581c555c5b537f552d885c1959c714282eb6ac06de5e2aee850c374d394e00f6"
}
```


**Submit certificate in a transaction**

1. Submit the SanchoNet DRep registration certificate in a transaction.

- Build:

```
cardano-cli conway transaction build \
--testnet-magic 4 \
--witness-override 2 \
--tx-in $(cardano-cli query utxo --address $(cat payment.addr) --testnet-magic 4 --out-file  /dev/stdout | jq -r 'keys[0]') \
--change-address $(cat payment.addr) \
--certificate-file drep-register.cert \
--out-file tx.raw
```


- Sign:

```
cardano-cli conway transaction sign \
--tx-body-file tx.raw \
--signing-key-file payment.skey \
--signing-key-file drep.skey \
--testnet-magic 4 \
--out-file tx.signed
```

- Submit:

```
cardano-cli conway transaction submit \
--testnet-magic 4 \
--tx-file tx.signed
```

Registering as a SanchoNet delegate representative (DRep)

In certain scenarios, a Delegate Representative (DRep) may comprise multiple individuals collectively involved in decision-making processes. Registering a multisignature DRep proves to be an optimal mechanism for such collaborative setups.

We can utilize Native scripts to register a multisignature DRep. In this example, we will establish a multisignature DRep composed of three sets of keys, where the endorsement of two out of the three sets is necessary.

**Pre-requisites**

- Payment address with funds
- A SanchoNet node

**Generate SanchoNet DRep keys and an ID**

**info**
Each individual member of the DRep must generate a DRep key pair and calculate its verification key hash (a DRep ID). Later on we will use the key hashes to build the Native script.

1. Generate a DRep key pair:

```
cardano-cli conway governance drep key-gen \
--verification-key-file drep1.vkey \
--signing-key-file drep1.skey
```

```
{
    "type": "DRepSigningKey_ed25519",
    "description": "Delegate Representative Signing Key",
    "cborHex": "5820eba7053fdc9cb3b8aacf142d3d4ad575bb48fb92f4082d81605ac8e2ccfead5d"
}
```


```
{
    "type": "DRepVerificationKey_ed25519",
    "description": "Delegate Representative Verification Key",
    "cborHex": "5820c19e0e939609531cfd04dcfa5bf1a5f3e245aa88e163759341aba296af34cc7e"
}
```


2. Get the DRep ID (verification key hash) in "hex" format:

```
cardano-cli conway governance drep id \
--drep-verification-key-file drep1.vkey \
--output-format hex \
--out-file drep1.id
```

```
cat drep1.id
e6d27c194fd18f39e080073e5ea02aa78abe4b6c84d78a498302461c
```

**Build the Native script**
Multi-signature scripts can be written using JSON syntax. This is the format that the `cardano-cli` tool accepts. In this example we want the script to evaluate to `True` if and only if **at least two valid sigantures are present**, this is captured by the fields `type` and `required`.

3. Use a text editor to build your script, let's name it drep-multisig.json:

```
{
  "type": "atLeast",
  "required": 2,
  "scripts": [
    {
      "type": "sig",
      "keyHash": "e6d27c194fd18f39e080073e5ea02aa78abe4b6c84d78a498302461c"
    },
    {
      "type": "sig",
      "keyHash": "5ab00e8cd1142fcffc5f7a2c2e3549874afd89e26995d7686c2714d4"
    },
    {
      "type": "sig",
      "keyHash": "db5a8cbb0df0359c36541727229993b21371f834202733c9bbabc1fd"
    }
  ]
}
```

We can choose a different type of script, for example type "any", where the script evaluates to `True` with a single valid signature from the list:

```
{
  "type": "any",
  "scripts": [
    {
      "type": "sig",
      "keyHash": "e6d27c194fd18f39e080073e5ea02aa78abe4b6c84d78a498302461c"
    },
    {
      "type": "sig",
      "keyHash": "5ab00e8cd1142fcffc5f7a2c2e3549874afd89e26995d7686c2714d4"
    },
    {
      "type": "sig",
      "keyHash": "db5a8cbb0df0359c36541727229993b21371f834202733c9bbabc1fd"
    }
  ]
}
```

Or for a more strict setup we can use type "all", where all the signatures are required:

```
{
  "type": "all",
  "scripts": [
    {
      "type": "sig",
      "keyHash": "e6d27c194fd18f39e080073e5ea02aa78abe4b6c84d78a498302461c"
    },
    {
      "type": "sig",
      "keyHash": "5ab00e8cd1142fcffc5f7a2c2e3549874afd89e26995d7686c2714d4"
    },
    {
      "type": "sig",
      "keyHash": "db5a8cbb0df0359c36541727229993b21371f834202733c9bbabc1fd"
    }
  ]
}
```

**Generate the DRep registration certificate**

4. We'll need the script hash (the DRep ID), calculate it with:

```
cardano-cli conway governance hash script \
  --script-file drep-multisig.json \
  --out-file drep-multisig.id
```

```
cat drep-multisig.id
d862ee2eb3ce246b23ff7e1f62ae0705013e793787485cb6e1845356
```

5. Get the DRep deposit amount and store in a variable:

`drepDeposit=$(cardano-cli conway query gov-state --testnet-magic 4 | jq -r .currentPParams.dRepDeposit)`


6. Generate the DRep registration certificate:

```
cardano-cli conway governance drep registration-certificate \
  --drep-script-hash "$(cat drep-multisig.id)" \
  --key-reg-deposit-amt "$drepDeposit" \
  --out-file drep-multisig-reg.cert
```

**Submit the Registration certificate in a transaction**

7. Build the transaction. Note that we use `--witness-override 4` because this tranaction will contain up to 4 signatures, 1 from the payment key and up to 3 members of the DRep.

```
cardano-cli conway transaction build \
  --testnet-magic 4 \
  --tx-in $(cardano-cli conway query utxo --address $(cat payment.addr) --testnet-magic 4 --output-json | jq -r 'keys[0]') \
  --change-address $(cat payment.addr) \
  --witness-override 4 \
  --certificate-file drep-multisig-reg.cert \
  --certificate-script-file drep-multisig.json \
  --out-file tx.raw
```


8. Each member of the DRep will witness the transaction with its individual keys from step 1. In addition, we need the witness from the payment address to pay for the transaction fee.

Witnessing the transaction with the payment key:

```
cardano-cli conway transaction witness \
  --testnet-magic 4 \
  --tx-body-file tx.raw \
  --signing-key-file payment.skey \
  --out-file payment.witness
```

Witnessing the transaction with the DRep keys from each memeber:

```
cardano-cli conway transaction witness \
  --testnet-magic 4 \
  --tx-body-file tx.raw \
  --signing-key-file drep1.skey \
  --out-file drep1.witness
```

```
cardano-cli conway transaction witness \
  --testnet-magic 4 \
  --tx-body-file tx.raw \
  --signing-key-file drep2.skey \
  --out-file drep2.witness
```

```
cardano-cli conway transaction witness \
  --testnet-magic 4 \
  --tx-body-file tx.raw \
  --signing-key-file drep3.skey \
  --out-file drep3.witness
```

9. Assemble the tranaction with all the witnesses from previous step:

```
cardano-cli transaction assemble \
  --tx-body-file tx.raw \
  --witness-file  payment.witness \
  --witness-file  drep1.witness \
  --witness-file  drep2.witness \
  --witness-file  drep3.witness \
  --out-file tx.signed
```

10. Submit the transaction

```
cardano-cli conway transaction submit \
  --testnet-magic 4 \
  --tx-file tx.signed
```

11. Query the DRep state to confirm

```
cardano-cli conway query drep-state \
  --testnet-magic 4 \
  --drep-script-hash $(cat drep-multisig.id)
```

```
[
    [
        {
            "scriptHash": "d862ee2eb3ce246b23ff7e1f62ae0705013e793787485cb6e1845356"
        },
        {
            "anchor": null,
            "deposit": 2000000,
            "expiry": 270
        }
    ]
]
```

Awesome! Now, we just need to delegate voting power to our DRep!

Registering a multisignature delegate representative (DRep)

Delegating your voting power to a SanchoNet delegate representative (DRep) operates much like delegating your stake to a stake pool. Voting power delegation involves the issuance of a delegation certificate from your stake key to the chosen SanchoNet DRep. Just as with stake delegation, the process of delegating votes to a SanchoNet DRep does not entail relinquishing control of your funds. Instead, the vote delegation certificate grants the selected DRep permission to vote on your behalf.

In addition to the registered SanchoNet DReps, the system features a couple of default DReps:

- --always-abstain: this option signals your intention not to participate in the voting procedures, indicating a choice to abstain from the voting process

- --always-no-confidence: this option signifies your lack of trust in the current constitutional committee, indicating a vote of no confidence in their decisions

**Prerequisites**

- Payment keys and address with funds
- Stake key
- Default SanchoNet DRep selection: `--always-abstain` or `--always-no-confidence`
- SanchoNet DRep ID (key hash or script hash) of a registered DRep. See useful cli queries
- A SanchoNet node

**Generating the vote delegation certificate**

1. Generate the vote delegation certificate.

- Delegating to the `--always-abstain` default DRep:

```
cardano-cli conway stake-address vote-delegation-certificate \
  --stake-verification-key-file stake.vkey \
  --always-abstain \
  --out-file vote-deleg.cert
```

- Delegating to the `--always-no-confidence` default DRep:

```
cardano-cli conway stake-address vote-delegation-certificate \
  --stake-verification-key-file stake.vkey \
  --always-no-confidence \
  --out-file vote-deleg.cert
```

- Delegating to a **key-based** registered SanchoNet DRep:

```
cardano-cli conway stake-address vote-delegation-certificate \
  --stake-verification-key-file stake.vkey \
  --drep-key-hash $(cat drep.id) \
  --out-file vote-deleg.cert
```

- Delegating to a **script-based** (i.e. multisignature) registered SanchoNet DRep:

```
cardano-cli conway stake-address vote-delegation-certificate \
--stake-verification-key-file stake.vkey \
--drep-script-hash $(cat drep-multisig.id) \
--out-file vote-deleg.cert
```

**Submitting the certificate in a transaction**

1. Submit the vote delegation certificate in a transaction.

- Build:

```
cardano-cli conway transaction build \
--testnet-magic 4 \
--witness-override 2 \
--tx-in $(cardano-cli query utxo --address $(cat payment.addr) --testnet-magic 4 --out-file  /dev/stdout | jq -r 'keys[0]') \
--change-address $(cat payment.addr) \
--certificate-file vote-deleg.cert \
--out-file tx.raw
```


- Sign with payment and stake keys:

```
cardano-cli conway transaction sign \
--tx-body-file tx.raw \
--signing-key-file payment.skey \
--signing-key-file stake.skey \
--testnet-magic 4 \
--out-file tx.signed
```

- Submit:

```
cardano-cli conway transaction submit \
--testnet-magic 4 \
--tx-file tx.signed
```

Delegate votes to a DRep

**Committee member cold keys**
Individuals who are to be nominated as committee members are required to generate a cold key pair. This requirement stems from the necessity to include the cold verification key (or its hash) in the governance action supporting their proposal. The term 'cold key pair' is used to emphasize its intentional storage in a secure, offline environment, which may include safeguarded USB drives, isolated computing machines, or similar devices deliberately disconnected from the internet for enhanced security.

```
cardano-cli conway governance committee key-gen-cold \
    --cold-verification-key-file cc-cold.vkey \
    --cold-signing-key-file cc-cold.skey
```

**Generate the cold verification key hash:**

```
cardano-cli conway governance committee key-hash \
    --verification-key-file cc-cold.vkey > cc-key.hash
```

```
cat cc-key.hash
89181f26b47c3d3b6b127df163b15b74b45bba7c3b7a1d185c05c2de
```

The key hash would be typically used in the **update committee** governance action that attempts to add or remove CC members.

**Hot key pair and authorization certificate**
After new committee members have been ratified by a governance action, the new committee members are required to generate a hot key pair and issue a hot key authorization certificate. This enables them to cast votes by signing their transactions with their hot signing key while keeping their cold keys securely stored in cold storage. In the event that the hot keys are compromised at any point, the committee member must generate a new hot key pair and issue a new hot key authorization certificate.

```
cardano-cli conway governance committee key-gen-hot \
    --verification-key-file cc-hot.vkey \
    --signing-key-file cc-hot.skey
```

```
cardano-cli conway governance committee create-hot-key-authorization-certificate \
    --cold-verification-key-file cc-cold.vkey \
    --hot-key-file cc-hot.vkey \
    --out-file cc-hot-key-authorization.cert
```


- Submit the authorization certificate in a transaction:

```
cardano-cli conway transaction build \
  --testnet-magic 4 \
  --tx-in "$(cardano-cli query utxo --address "$(cat payment.addr)" --testnet-magic 4 --out-file /dev/stdout | jq -r 'keys[0]')" \
  --change-address payment.addr \
  --certificate-file cc-hot-key-authorization.cert \
  --witness-override 2 \
  --out-file tx.raw
```


```
cardano-cli conway transaction sign \
  --testnet-magic 4 \
  --tx-body-file tx.raw \
  --signing-key-file payment.skey \
  --signing-key-file cc-cold.skey \
  --out-file tx.signed
```

```
cardano-cli conway transaction submit \
  --testnet-magic 4 \
  --tx-file tx.signed
```

Generate committee member keys and certificates

**Pre-requisites**

- Payment key pair
- Address with funds
- CC hot, DRep OR stake pool keys
- A SanchoNet node

To vote on governance actions, follow this process:

1. Obtain the action ID of an ongoing governance action from Discord or query the governance state.
2. Determine your voting stance; engage in discussion if required
3. Construct your vote file through the Cardano CLI. The example below demonstrates voting `--yes`, although options for `--no` or `--abstain` are also available.

**Verify the content of the governance action**
Assume that we have been given the action ID `df58f714c0765f3489afb6909384a16c31d600695be7e86ff9c59cf2e8a48c79#0` for a new constitution proposal.

1. Obtain the URL and hash of the new constitution proposal from the governance state:

```
cardano-cli conway query gov-state --testnet-magic 4 | \
jq -r --arg govActionId "df58f714c0765f3489afb6909384a16c31d600695be7e86ff9c59cf2e8a48c79" '.proposals | to_entries[] | select(.value.actionId.txId | contains($govActionId)) | .value'
```


```
{
  "action": {
    "contents": [
      null,
      {
        "anchor": {
          "dataHash": "5d372dca1a4cc90d7d16d966c48270e33e3aa0abcb0e78f0d5ca7ff330d2245d",
          "url": "https://tinyurl.com/mr3ferf9"
        }
      }
    ],
    "tag": "NewConstitution"
  },
  "actionId": {
    "govActionIx": 0,
    "txId": "df58f714c0765f3489afb6909384a16c31d600695be7e86ff9c59cf2e8a48c79"
  },
  "committeeVotes": {
    "keyHash-c8ac605b25d6084c2ceb28043c8f01b62629966d038a249c7847d66d": "VoteYes",
    "keyHash-d13507f7e7fb8ac3ce2094187c9d99d4601021e9ef5a5f310567765d": "VoteYes"
  },
  "dRepVotes": {
    "keyHash-16faaf6daa2635bbf53bbbaf38b3a6040adf7ced2f7f08952592cf5b": "VoteYes",
    "keyHash-57cb90cfb635e76af648abf1b6a91519218a5919b3cba2527e3725d1": "VoteYes",
    "keyHash-7d84808d563f0f258ad7e4337c2c4bd13010930ebdf7b86c3bfd9ef8": "VoteYes"
  },
  "deposit": 0,
  "expiresAfter": 80,
  "proposedIn": 78,
  "returnAddr": {
    "credential": {
      "keyHash": "f925cbd4eb78aad49ec7bf9b4ddfa4cc4486c967e392699d143c81aa"
    },
    "network": "Testnet"
  },
  "stakePoolVotes": {}
}
```


2. Download the file from the URL registered on the ledger state:

`wget https://tinyurl.com/mr3ferf9 -O constitution.txt`

3. Verify that the hash of the file matches the `dataHash`from the ledger state:

```
b2sum -l 256 constitution.txt
5d372dca1a4cc90d7d16d966c48270e33e3aa0abcb0e78f0d5ca7ff330d2245d  constitution.txt
```


**Everything is in order; the text at the URL matches the dataHash, confirming that the text at the URL is precisely what we are voting for.**

In the future, voting apps, explorers, wallets, and other tools could perform the filtering, ensuring that they only display actions whose URL content has been verified against the hash on the ledger state.

**Create the vote file**

1. Vote with DRep keys:

```
cardano-cli conway governance vote create \
    --yes \
    --governance-action-tx-id "df58f714c0765f3489afb6909384a16c31d600695be7e86ff9c59cf2e8a48c79" \
    --governance-action-index "0" \
    --drep-verification-key-file drep.vkey \
    --out-file df58f714c0765f3489afb6909384a16c31d600695be7e86ff9c59cf2e8a48c79-constitution.vote
```


2. Vote with CC hot keys:

```
cardano-cli conway governance vote create \
    --yes \
    --governance-action-tx-id "df58f714c0765f3489afb6909384a16c31d600695be7e86ff9c59cf2e8a48c79" \
    --governance-action-index "0" \
    --cc-hot-verification-key-file cc-hot.vkey \
    --out-file df58f714c0765f3489afb6909384a16c31d600695be7e86ff9c59cf2e8a48c79-constitution.vote
```


3. Vote with SPO keys:

```
cardano-cli conway governance vote create \
    --yes \
    --governance-action-tx-id "df58f714c0765f3489afb6909384a16c31d600695be7e86ff9c59cf2e8a48c79" \
    --governance-action-index "0" \
    --cold-verification-key-file cold.vkey \
    --out-file df58f714c0765f3489afb6909384a16c31d600695be7e86ff9c59cf2e8a48c79-constitution.vote
```


**Include the vote in a transaction**

- Build the transaction:

```
cardano-cli conway transaction build --testnet-magic 4 \
    --tx-in "$(cardano-cli query utxo --address $(cat payment.addr) --testnet-magic 4 --out-file /dev/stdout | jq -r 'keys[0]')" \
    --change-address $(cat payment.addr) \
    --vote-file df58f714c0765f3489afb6909384a16c31d600695be7e86ff9c59cf2e8a48c79-constitution.vote \
    --witness-override 2 \
    --out-file vote-tx.raw
```


- Sign it with the DRep key:

```
cardano-cli transaction sign --tx-body-file vote-tx.raw \
    --signing-key-file drep.skey \
    --signing-key-file payment.skey \
    --testnet-magic 4 \
    --out-file vote-tx.signed
```

- OR sign it with the CC hot key:

```
cardano-cli transaction sign --tx-body-file vote-tx.raw \
    --signing-key-file cc-hot.skey \
    --signing-key-file payment.skey \
    --testnet-magic 4 \
    --out-file vote-tx.signed
```

- OR sign it with the SPO cold key:

```
cardano-cli transaction sign --tx-body-file vote-tx.raw \
    --signing-key-file cold.skey \
    --signing-key-file payment.skey \
    --testnet-magic 4 \
    --out-file vote-tx.signed
```

- Submit the transaction:

`cardano-cli transaction submit --testnet-magic 4 --tx-file vote-tx.signed`

Voting on governance actions

**Pre-requisites**

- Payment key pair
- Address with funds
- Multisignature DRep. See Register multisig DRep
- A SanchoNet node

To vote on governance actions, follow this process:

1. Obtain the action ID of an ongoing governance action from Discord or query the governance state.
2. Determine your voting stance; engage in discussion if required
3. Construct your vote file through the Cardano CLI. The example below demonstrates voting `--yes`, although options for `--no` or `--abstain` are also available.

**Verify the content of the governance action**

Assume that we have been given the action ID `df58f714c0765f3489afb6909384a16c31d600695be7e86ff9c59cf2e8a48c79#0` for a new constitution proposal.

1. Obtain the URL and hash of the new constitution proposal from the governance state:

```
cardano-cli conway query gov-state --testnet-magic 4 | \
jq -r --arg govActionId "df58f714c0765f3489afb6909384a16c31d600695be7e86ff9c59cf2e8a48c79" '.proposals | to_entries[] | select(.value.actionId.txId | contains($govActionId)) | .value'
```


```
{
  "action": {
    "contents": [
      null,
      {
        "anchor": {
          "dataHash": "5d372dca1a4cc90d7d16d966c48270e33e3aa0abcb0e78f0d5ca7ff330d2245d",
          "url": "https://tinyurl.com/mr3ferf9"
        }
      }
    ],
    "tag": "NewConstitution"
  },
  "actionId": {
    "govActionIx": 0,
    "txId": "df58f714c0765f3489afb6909384a16c31d600695be7e86ff9c59cf2e8a48c79"
  },
  "committeeVotes": {
    "keyHash-c8ac605b25d6084c2ceb28043c8f01b62629966d038a249c7847d66d": "VoteYes",
    "keyHash-d13507f7e7fb8ac3ce2094187c9d99d4601021e9ef5a5f310567765d": "VoteYes"
  },
  "dRepVotes": {
    "keyHash-16faaf6daa2635bbf53bbbaf38b3a6040adf7ced2f7f08952592cf5b": "VoteYes",
    "keyHash-57cb90cfb635e76af648abf1b6a91519218a5919b3cba2527e3725d1": "VoteYes",
    "keyHash-7d84808d563f0f258ad7e4337c2c4bd13010930ebdf7b86c3bfd9ef8": "VoteYes"
  },
  "deposit": 0,
  "expiresAfter": 80,
  "proposedIn": 78,
  "returnAddr": {
    "credential": {
      "keyHash": "f925cbd4eb78aad49ec7bf9b4ddfa4cc4486c967e392699d143c81aa"
    },
    "network": "Testnet"
  },
  "stakePoolVotes": {}
}
```


2. Download the file from the URL registered on the ledger state:

`wget https://tinyurl.com/mr3ferf9 -O constitution.txt`

3. Verify that the hash of the file matches the dataHashfrom the ledger state:

```
b2sum -l 256 constitution.txt
5d372dca1a4cc90d7d16d966c48270e33e3aa0abcb0e78f0d5ca7ff330d2245d  constitution.txt
```


**Everything is in order; the text at the URL matches the dataHash, confirming that the text at the URL is precisely what we are voting for.**

In the future, voting apps, explorers, wallets, and other tools could perform the filtering, ensuring that they only display actions whose URL content has been verified against the hash on the ledger state.

**Create the vote file**

1. Vote with DRep keys:

```
cardano-cli conway governance vote create \
  --yes \
  --governance-action-tx-id "df58f714c0765f3489afb6909384a16c31d600695be7e86ff9c59cf2e8a48c79" \
  --governance-action-index "0" \
  --drep-script-hash $(cat drep-multisig.id) \
  --out-file df58f714c0765f3489afb6909384a16c31d600695be7e86ff9c59cf2e8a48c79-constitution.vote
``` 


**Include the vote in a transaction**

2. Build the transaction:

```
cardano-cli conway transaction build \
    --testnet-magic 4 \
    --tx-in-script-file drep-multisig.json \
    --tx-in "$(cardano-cli query utxo --address $(cat payment.addr) --testnet-magic 4 --output-json | jq -r 'keys[0]')" \
    --change-address $(cat payment.addr) \
    --vote-file df58f714c0765f3489afb6909384a16c31d600695be7e86ff9c59cf2e8a48c79-constitution.vote \
    --witness-override 4 \
    --out-file vote-tx.raw
```


3. Every member of the DRep witnesses the transaction with their respective signing keys. Additionally, we need to witness the transaction with the payment signing key:

```
cardano-cli conway transaction witness \
  --tx-body-file vote-tx.raw \
  --signing-key-file drep1.skey \
  --out-file drep1.witness
```

```
cardano-cli conway transaction witness \
  --tx-body-file vote-tx.raw \
  --signing-key-file drep2.skey \
  --out-file drep2.witness
```

```
cardano-cli conway transaction witness \
  --tx-body-file vote-tx.raw \
  --signing-key-file drep3.skey \
  --out-file drep3.witness
```

```
cardano-cli conway transaction witness \
  --tx-body-file vote-tx.raw \
  --signing-key-file payment.skey \
  --out-file payment.witness
```

4. Assemble the transaction:

```
cardano-cli transaction assemble \
  --tx-body-file vote-tx.raw \
  --witness-file  payment.witness \
  --witness-file  drep1.witness \
  --witness-file  drep2.witness \
  --witness-file  drep3.witness \
  --out-file vote-tx.signed
```

5. Submit the transaction:

`cardano-cli transaction submit --testnet-magic 4 --tx-file vote-tx.signed`

Voting on governance actions as a multisignature DRep

*'jq is like sed for JSON data - you can use it to slice, filter, map, and transform structured data with the same ease that sed, awk, grep and friends let you play with text.'*

[Install jq](https://jqlang.github.io/jq/download/).

Below you will find some useful jq filters to parse the governance state.

**Show governance actions that will expire at the end of the current epoch:**

`current_epoch=$(cardano-cli query tip --testnet-magic 4 | jq .epoch)`

```
cardano-cli conway query gov-state --testnet-magic 4 \
    | jq --argjson epoch "$current_epoch" '.proposals
    | to_entries[]
    | select(.value.expiresAfter == $epoch)'
```


**Show governance actions that were proposed in the current epoch:**

`current_epoch=$(cardano-cli query tip --testnet-magic 4 | jq .epoch)`

```
cardano-cli conway query gov-state --testnet-magic 4 \
    | jq -r --argjson epoch "$current_epoch" '.proposals
    | to_entries[]
    | select(.value.proposedIn == $epoch)'
```

**Sort governance actions by the number of DRep votes:**

```
cardano-cli conway query gov-state --testnet-magic 4 | jq -r '
  .proposals
  | to_entries[]
  | {govActionId: .value.actionId, type: .value.proposalProcedure.govAction.tag, drepVoteCount: (.value.dRepVotes | keys | length)}
  ' | jq -s 'sort_by(.voteCount) | reverse[]'
```



**Sort by the number of SPO votes:**

```
cardano-cli conway query gov-state --testnet-magic 4 | jq -r '
  .proposals
  | to_entries[]
  | {govActionId: .value.actionId, type: .value.proposalProcedure.govAction.tag, spoVoteCount: (.value.stakePoolVotes | keys | length)}
  ' | jq -s 'sort_by(.voteCount) | reverse[]'
```


**Sort by the number of CC votes:**

```
cardano-cli conway query gov-state --testnet-magic 4 | jq -r '
  .proposals
  | to_entries[]
  | {govActionId: .value.actionId, type: .value.proposalProcedure.govAction.tag, ccVoteCount: (.value.committeeVotes | keys | length)}
  ' | jq -s 'sort_by(.voteCount) | reverse[]'
```


**Filter actions that expire within the current and the next two epochs, including information about all roles' votes, sorted by expiration epoch:**

`current_epoch=$(cardano-cli query tip --testnet-magic 4 | jq .epoch)`

```
cardano-cli conway query gov-state --testnet-magic 4 | jq -r --argjson current_epoch "$current_epoch" '
  .proposals
  | to_entries[]
  | select(.value.expiresAfter >= ($current_epoch | tonumber) and .value.expiresAfter <= ($current_epoch + 2))
  | {
      govActionId: .value.actionId,
      type: .value.proposalProcedure.govAction.tag,
      expiresAfter: .value.expiresAfter,
      committeeVotesCount: (.value.committeeVotes | length),
      dRepVotesCount: (.value.dRepVotes | length),
      stakePoolVotesCount: (.value.stakePoolVotes | length)
    }
  ' | jq -s 'sort_by(.expiresAfter)'
```



**Show actions for which a specific DRep key has voted, indicating the DRep's vote and the total number of votes received for this action:**
Replace `keyHash-0e7d17c8a917eaee361924d6471331128b3e0de5323f54d70dd0c8c9` with the hex DRep ID of your interest, if it is a script based DRRep, make sure to use `scriptHash` instead of `keyHash` prefix.

```
cardano-cli conway query gov-state --testnet-magic 4 | jq -r --arg dRepKey "keyHash-0e7d17c8a917eaee361924d6471331128b3e0de5323f54d70dd0c8c9" '
  .proposals
  | to_entries[]
  | select(.value.dRepVotes[$dRepKey] != null)
  | {
      govActionId: .value.actionId,
      type: .value.proposalProcedure.govAction.tag,
      dRepVote: .value.dRepVotes[$dRepKey],
      expiresAfter: .value.expiresAfter,
      committeeVotesCount: (.value.committeeVotes | length),
      dRepVotesCount: (.value.dRepVotes | length),
      stakePoolVotesCount: (.value.stakePoolVotes | length)
    }
  '
```


**Show actions where the given DRep key has not voted yet:**

Replace `058b60ead63f667c0ff5b40e269dd1f05ce3a804256735ad4eddce20` with the hex DRep ID of your interest.

```
cardano-cli conway query gov-state --testnet-magic 4 | jq -r --arg dRepKey "keyHash-0e7d17c8a917eaee361924d6471331128b3e0de5323f54d70dd0c8c9" '
  .proposals
  | to_entries[]
  | select(.value.dRepVotes[$dRepKey] == null)
  | {
      govActionId: .value.actionId,
      type: .value.proposalProcedure.govAction.tag,
      expiresAfter: .value.expiresAfter,
      committeeVotesCount: (.value.committeeVotes | length),
      dRepVotesCount: (.value.dRepVotes | length),
      stakePoolVotesCount: (.value.stakePoolVotes | length)
    }
  '
```


**Show the total number of 'yes', 'no', and 'abstain' votes for a given governance action ID:**

Replace "1e08794a48b71ec7e48d3190c7c30455f9538d0e54f4087915ff201167334bc7" and "0" and with the governance action ID and index of your interest.

and .value.actionId.govActionIx == $actionIndex

```
cardano-cli conway query gov-state --testnet-magic 4 \
  | jq -r --arg actionTxId "1e08794a48b71ec7e48d3190c7c30455f9538d0e54f4087915ff201167334bc7" --arg actionIndex "0" ' .proposals
  | to_entries[]
  | select(.value.actionId.txId == $actionTxId and .value.actionId.govActionIx == ($actionIndex | tonumber))
  | {
      govActionId: .value.actionId,
      dRepVoteYesCount: (.value.dRepVotes | with_entries(select(.value == "VoteYes")) | length),
      dRepVoteNoCount: (.value.dRepVotes | with_entries(select(.value == "VoteNo")) | length),
      dRepAbstainCount: (.value.dRepVotes | with_entries(select(.value == "Abstain")) | length),
      stakePoolVoteYesCount: (.value.stakePoolVotes | with_entries(select(.value == "VoteYes")) | length),
      stakePoolVoteNoCount: (.value.stakePoolVotes | with_entries(select(.value == "VoteNo")) | length),
      stakePoolAbstainCount: (.value.stakePoolVotes | with_entries(select(.value == "Abstain")) | length),
      committeeVoteYesCount: (.value.committeeVotes | with_entries(select(.value == "VoteYes")) | length),
      committeeVoteNoCount: (.value.committeeVotes | with_entries(select(.value == "VoteNo")) | length),
      committeeAbstainCount: (.value.committeeVotes | with_entries(select(.value == "Abstain")) | length)
    }
'
```


**Show the active `treasury withdrawal` governance actions and their current vote count:**

```
current_epoch=$(cardano-cli query tip --testnet-magic 4 | jq .epoch)

cardano-cli conway query gov-state --testnet-magic 4 | jq -r --arg currentEpoch "$current_epoch" '
  .proposals
  | to_entries[]
  | select(.value.expiresAfter > ($currentEpoch | tonumber) and .value.proposalProcedure.govAction.tag == "TreasuryWithdrawals")
  | { type: .value.proposalProcedure.govAction.tag, 
      govActionId: .value.actionId,
      expiresAfter: .value.expiresAfter,
      dRepVoteYesCount: (.value.dRepVotes | with_entries(select(.value == "VoteYes")) | length),
      dRepVoteNoCount: (.value.dRepVotes | with_entries(select(.value == "VoteNo")) | length),
      dRepAbstainCount: (.value.dRepVotes | with_entries(select(.value == "Abstain")) | length),
      committeeVoteYesCount: (.value.committeeVotes | with_entries(select(.value == "VoteYes")) | length),
      committeeVoteNoCount: (.value.committeeVotes | with_entries(select(.value == "VoteNo")) | length),
      committeeAbstainCount: (.value.committeeVotes | with_entries(select(.value == "Abstain")) | length)
    }
' | jq -s 'sort_by(.expiresAfter)'
```



**Show the active `update committee` governance actions and their current vote count:
current_epoch=$(cardano-cli query tip --testnet-magic 4 | jq .epoch)**

```
cardano-cli conway query gov-state --testnet-magic 4 | jq -r --arg currentEpoch "$current_epoch" '
  .proposals
  | to_entries[]
  | select(.value.expiresAfter > ($currentEpoch | tonumber) and.value.proposalProcedure.govAction.tag == "UpdateCommittee")
  | { type: .value.proposalProcedure.govAction.tag,
      govActionId: .value.actionId,
      expiresAfter: .value.expiresAfter,
      dRepVoteYesCount: (.value.dRepVotes | with_entries(select(.value == "VoteYes")) | length),
      dRepVoteNoCount: (.value.dRepVotes | with_entries(select(.value == "VoteNo")) | length),
      dRepAbstainCount: (.value.dRepVotes | with_entries(select(.value == "Abstain")) | length),
      stakePoolVoteYesCount: (.value.stakePoolVotes | with_entries(select(.value == "VoteYes")) | length),
      stakePoolVoteNoCount: (.value.stakePoolVotes | with_entries(select(.value == "VoteNo")) | length),
      stakePoolAbstainCount: (.value.stakePoolVotes | with_entries(select(.value == "Abstain")) | length)
    }
' | jq -s 'sort_by(.expiresAfter)'
```

Useful jq filters

**Query the constitution:**

```
cardano-cli conway query constitution --testnet-magic 4
{
    "anchor": {
        "dataHash": "5d372dca1a4cc90d7d16d966c48270e33e3aa0abcb0e78f0d5ca7ff330d2245d",
        "url": "https://tinyurl.com/4xdkkjm3"
    }
}
```

**Query the DRep state for all DReps:**

```
cardano-cli conway query drep-state --testnet-magic 4 --all-dreps


[
    [
        {
            "scriptHash": "1d8fe9486b5fb282287568f04445c8f4d6cddf76ce2df527fd7debbe"
        },
        {
            "anchor": null,
            "deposit": 2000000,
            "expiry": 108
        }
    ],
    [
        {
            "keyHash": "1da9afe241a10fe5ee9590843134d0eebd4a32af448c9ec91db2e863"
        },
        {
            "anchor": null,
            "deposit": 2000000,
            "expiry": 177
        }
    ],
    [
        {
            "keyHash": "480036de36a123e98663370e4829ebd43aa9bb06ec4b6b25f3e178db"
        },
        {
            "anchor": null,
            "deposit": 2000000,
            "expiry": 176
        }
    ],
    [
        {
            "keyHash": "5b440956e056c96c74d4820b39b4f91cc45bb2b46024c96a594bb2ed"
        },
        {
            "anchor": null,
            "deposit": 2000000,
            "expiry": 176
        },

    ]
]
```

**Query the DRep state for an individual DRep:**

```
cardano-cli conway query drep-state --drep-key-hash 1da9afe241a10fe5ee9590843134d0eebd4a32af448c9ec91db2e863 --testnet-magic 4
[
    [
        {
            "keyHash": "1da9afe241a10fe5ee9590843134d0eebd4a32af448c9ec91db2e863"
        },
        {
            "anchor": null,
            "deposit": 2000000,
            "expiry": 188
        }
    ]
]
```

**Query the DRep stake distribution (voting power):**

```
cardano-cli conway query drep-stake-distribution --testnet-magic 4
[
    [
        "drep-keyHash-13797df5308dfebf2348fa58b312a177cf97939f5f7d21168e1a54db",
        500000000000
    ],
    [
        "drep-keyHash-9853551d8b99884f51608822e012bbf0d444eb7bea2807ee664f1241",
        495790521257
    ],
    [
        "drep-keyHash-cf09b59e134fa14e48da39b552c02299a054d7c8b895b3d827453672",
        500000000000
    ]
]
```

**Query the committee state:**

```
cardano-cli conway query committee-state --testnet-magic 4
{
    "committee": {
        "keyHash-5e86313210aef13297187c38c98abb632678906230f555a1bf0a647a": {
            "expiration": 161,
            "hotCredsAuthStatus": {
                "contents": {
                    "keyHash": "e394a160b9f1345b7b84cd25f0a3f1d12cb0c9835a4167f7dc5b52ca"
                },
                "tag": "MemberAuthorized"
            },
            "nextEpochChange": "NoChangeExpected",
            "status": "Active"
        },
        "keyHash-8be41436ce39ca3c2f3e4255e17fc6c11581ef6787bccf9ab60f39dd": {
            "expiration": 181,
            "hotCredsAuthStatus": {
                "contents": {
                    "keyHash": "e6442af170fabe877ba6b23136ffb32026e9ed927158ecdda2ef0e18"
                },
                "tag": "MemberAuthorized"
            },
            "nextEpochChange": "NoChangeExpected",
            "status": "Active"
        },
        "keyHash-da9f5c5c94a6709a9188838ce8cd7fe1c39a1923de4933c16d67c1e0": {
            "expiration": 201,
            "hotCredsAuthStatus": {
                "contents": {
                    "keyHash": "f380b5c4f245f9987645023e39b487e11a7d2337aea91dde628d04ed"
                },
                "tag": "MemberAuthorized"
            },
            "nextEpochChange": "NoChangeExpected",
            "status": "Active"
        }
    },
    "epoch": 86,
    "quorum": 0.6666666666666666666
}
```

**Query the state of an individual committee key hash:**

```
cardano-cli conway query committee-state --cold-verification-key-hash da9f5c5c94a6709a9188838ce8cd7fe1c39a1923de4933c16d67c1e0 --testnet-magic 4
{
    "committee": {
        "keyHash-da9f5c5c94a6709a9188838ce8cd7fe1c39a1923de4933c16d67c1e0": {
            "expiration": 201,
            "hotCredsAuthStatus": {
                "contents": {
                    "keyHash": "f380b5c4f245f9987645023e39b487e11a7d2337aea91dde628d04ed"
                },
                "tag": "MemberAuthorized"
            },
            "nextEpochChange": "NoChangeExpected",
            "status": "Active"
        }
    },
    "epoch": 89,
    "quorum": 0.6666666666666666666
}
```

**Query expired committee members**

```
cardano-cli conway query committee-state --expired --testnet-magic 4
{
    "committee": {
        "keyHash-059349cd1e77dc3e500d3ffc498adb7307001ecc022c8b083faaa48b": {
            "expiration": 161,
            "hotCredsAuthStatus": {
                "contents": {
                    "keyHash": "23e05ad2b71317a6348ce4b68dae37aa1c0e545cdea740b23c21742e"
                },
                "tag": "MemberAuthorized"
            },
            "nextEpochChange": "NoChangeExpected",
            "status": "Expired"
        }
    },
    "epoch": 169,
    "quorum": 0.6
}
```

**Query active committee members**

```
cardano-cli conway query committee-state --active --testnet-magic 4
{
    "committee": {
        "keyHash-059349cd1e77dc3e500d3ffc498adb7307001ecc022c8b083faaa48b": {
            "expiration": 161,
            "hotCredsAuthStatus": {
                "contents": {
                    "keyHash": "23e05ad2b71317a6348ce4b68dae37aa1c0e545cdea740b23c21742e"
                },
                "tag": "MemberAuthorized"
            },
            "nextEpochChange": "NoChangeExpected",
            "status": "Active"
        },
        "keyHash-337e0a7fd01c7a7c27e8bac17e40db182bc2a774467795af1e3fe8a9": {
            "expiration": 201,
            "hotCredsAuthStatus": {
                "contents": {
                    "keyHash": "540bedcd4bdcbf523e899c3ef43f2b96ecec4f6303af58d15a413ed1"
                },
                "tag": "MemberAuthorized"
            },
            "nextEpochChange": "NoChangeExpected",
            "status": "Active"
        },
        "keyHash-9c2aabae5d9187a76ed6b04b40e91ecb4ce3171611c3fd4ec6c6a607": {
            "expiration": 181,
            "hotCredsAuthStatus": {
                "contents": {
                    "keyHash": "6c1d098a366f2274651943a7f778b3b5459c129f0407a0db2902253a"
                },
                "tag": "MemberAuthorized"
            },
            "nextEpochChange": "NoChangeExpected",
            "status": "Active"
        }
    },
    "epoch": 105,
    "quorum": 0.6
}
```

**Query unrecognized committee keys**

```
cardano-cli conway query committee-state --unrecognized --testnet-magic 42
{
    "committee": {},
    "epoch": 106,
    "quorum": 0.6
}
```

Useful CLI queries

Tutorials

**Overview**

The DRep training program is designed to enable participants to learn the skills and knowledge they need to effectively participate as Delegate Representatives (DReps) in the governance structure proposed for Cardano.

This documentation serves as a comprehensive guide for DRep Pioneers, who will play a pivotal role as instructors in training individuals from the Cardano Community interested in becoming DReps.

Disclaimer: The mention of any third-party software or tools in this document is for informational purposes only. We do not endorse, recommend, or have any affiliation with the mentioned third-party software. Participants and instructors are encouraged to conduct their own research and due diligence before using any third-party software, and we accept no responsibility for any consequences arising from the use of such software.

**Learning Objectives**
By the end of this training, participants will be able to:

- Understand the fundamentals of Cardano’s on-chain governance design.
- Understand the role and expectations of a DRep.
- Gain the skills to effectively become a DRep - both the practical and the ‘softer’ skills (e.g., marketing, building relationships).
- Engage with the Cardano community using the available tools for DReps.

**Goals of the DRep Pioneer Program**

Intersect would like to sponsor a DRep Pioneer Program by inviting selected members to deliver the course to the Cardano community as Pioneer Workshop Leaders.

By the end of the program, a significant part of the community will be equipped with the knowledge and skills needed to effectively participate in the new governance role - DRep.

A major goal of this initiative is to develop a continuous learning program that will support the first cohort of DReps’ to be able to effectively perform their role in Cardano’s proposed governance design.

A further goal of the program is to create materials that can be used ‘standalone’ independent from the training courses, so that a potential DRep can train themselves on what is required in an intuitive and clear way.

Overview and Goals

**Participants Requirements**

All participants should hold ada to participate as DReps. Participation in this training does not ensure that participants will be accepted as DReps by the Cardano community.

**Participants Preliminary Knowledge**

To successfully complete this training, participants should:

- Understand how the Cardano blockchain works.
- Be familiar with Cardano wallets and how they work.

**Participants Preparation**
To participate in the training, participants should have the following:

- Any of the following web browsers: Google Chrome, Brave, or Microsoft Edge.
- A CIP-95 capable wallet with an active address. The list of compatible wallets can be found [here](https://docs.sanchogov.tools/how-to-use-the-govtool/getting-started/get-a-compatible-wallet).
- A reliable internet connection, if you are attending the DRep training online.

**Instructor Requirements**
All instructors should have participated in the DRep Pioneers Programs and completed the corresponding training. All instructors are required to join as DReps in the Cardano Governance structure.

**Instructor Preparation**
This training is designed as a six-hour course that can be offered online or in person. Instructors should consider additional time for breaks and meals.

**General Considerations**

Regardless of the type of training, online or in person, we encourage you to consider the following:

- Promote the training session on your social media, write a blog post on your personal or professional website, or contribute to Essential Cardano; you can learn more about it at this [link](https://www.essentialcardano.io/contribute-help).
- When promoting your training session, create a registration form to gather participants' information and kindly ask if they would like to receive news and further steps after the training.
- Maintain a visible and active presence throughout the session to foster community and participant connection. Use inclusive language and acknowledge contributions from all participants to create a supportive learning environment.
- As an instructor, you should be prepared to adapt your teaching style and approach based on the participants' needs and preferences. You should also be flexible, responsive to feedback, and willing to modify the lesson plan or activities to accommodate different learning styles and abilities.
- Optionally, take pictures and record videos from your training session for your records and future session promotion. It’s vital to ask for explicit consent from participants to appear in the pictures and videos. You can ask for it in the registration form.
- After the session, use the provided form to solicit participant feedback to identify strengths and areas for improvement. Use this feedback to refine future sessions and adapt your approach to meet your audience's needs better.

**Considerations for Online Training Sessions**

To provide a thriving online session, please take into consideration the following:

- Use a reliable internet connection. A wired connection is highly recommended to reduce the risk of signal loss.
- Choose an appropriate videoconferencing or video streaming software and test it before the session.
- Online classes can sometimes lead to reduced engagement compared to in-person sessions. Plan interactive activities, discussions, polls, and quizzes to keep participants engaged throughout the session. Encourage participation through the chat function or by using video or audio interactions.
- Utilize visual aids such as slides, videos, live coding, and interactive whiteboards to enhance understanding and retention of the material. Ensure that visual aids are clear, relevant, and accessible to all participants.
- Provide opportunities for participants to receive feedback on their progress and understanding of the material. Incorporate quizzes, polls, or short assignments to assess comprehension and reinforce key concepts.
- Online classes may require extra time for technical troubleshooting or concept clarification. Plan additional time for these potential issues while ensuring the session stays on schedule. Break the session into manageable segments with built-in breaks to prevent participant fatigue.
- Have a plan to address technical issues that may arise during the session. Depending on the software and tools you will use, designate a technical support staff member or provide troubleshooting resources for participants to resolve common issues independently.

**Considerations for In-Person Training Sessions**
To offer an engaging in-person training session, please consider the following:

- Ensure that the physical classroom is conducive to learning. This includes adequate lighting, comfortable seating, proper ventilation, and appropriate room temperature. Arrange the furniture to promote interaction and engagement among participants.
- Prepare all necessary materials and resources in advance, such as handouts, visual aids, and equipment. Ensure that all materials are easily accessible to participants and that any technology or equipment functions correctly in the classroom.
- In an in-person setting, you can employ various engagement techniques to capture participants' attention and maintain their interest. These may include group discussions, hands-on activities, role-playing exercises, demonstrations, and interactive games.
- Encourage active participation from participants by asking questions, soliciting opinions, and inviting them to share their experiences and insights. Foster a collaborative learning environment where participants feel comfortable expressing themselves and engaging with one another.
- Prioritize the safety and well-being of participants by adhering to any relevant health and safety guidelines, such as maintaining physical distancing, wearing face masks, and sanitizing shared surfaces. Create a supportive and inclusive learning environment where participants feel respected, valued, and supported in their learning journey.

Participation Requirements

**Proposed Schedule**
This lesson contains 12 activities covering all the DRep program content. In addition to these activities, instructors should consider breaks throughout the day according to the local culture and manners, such as lunchtime and refreshments that can be offered in the training session.

The following table shows a proposed schedule for a typical training session, with lunchtime around 1:00 p.m. Feel free to adapt the schedule and activity timing accordingly to your audience and local culture.

![](https://sancho.network/assets/images/drep-pp-plan-58ea1086813d36ed4d74d78d96086fb2.png)

DRep Pioneer Program Lesson Plan

**Activity 1: Welcome Participants (15 min)**

Welcome participants to the DRep Training; congratulate them for the decision to learn more about the DRep ecosystem and how they can become a DRep to participate in and vote in Cardano’s governance.

Use this time to introduce yourself and share your motivation to become a DRep. If time permits, conduct an ice-breaking activity to allow participants to introduce themselves. You can use the “popcorn” approach, where the last person to participate selects the next teammate to introduce themselves.

Keep introductions plain and straightforward by encouraging participants to answer two or three questions, such as:

1. What is your name?
2. How long have you been in the Cardano Community?
3. Why do you want to become a DRep?

The “popcorn” approach is a double-edged sword; however, it makes the meeting more democratic, with each team member selecting their successor. However, it can also make people feel awkward if they are unfamiliar with one another. If the introductions get stuck, act as a facilitator.

Be sure everyone introduces themselves before moving forward to the next activity.

**Activity 2: DRep Training Program Overview (15 min)**

Use the session schedule to present an overview of the content you will cover during the day; avoid getting into the details to prevent additional time spent. Use the training slides to present the learning outcomes and encourage participants to ask questions during the session.

Depending on your training type, in-person or online training, explain the session logistics for breaks and any relevant information.

Ask any questions before moving on to the next activity.

**Activity 3: Key Terms (15 min)**
For this activity, use the glossary in the training slides to present the key terms that participants should acknowledge to understand the forthcoming activities better.

To make this activity more engaging, you can conduct trivia to ask participants if they know the definition of every concept in the glossary. You can use slides or an online tool like [Kahoot](https://kahoot.com/) or [TriviaMaker](https://triviamaker.com/).

Ensure the terms are clear for participants before moving on to the next activity.

Prelude and Introductions

**Activity 4: Cardano’s On-Chain Governance Design (40 min)**

In this activity, participants will learn about the on-chain governance design, focusing on how the governance system is described on [CIP-1694](https://github.com/cardano-foundation/CIPs/blob/master/CIP-1694/README.md).

Open the training slides, navigate to the Module 1 section, and highlight the following talking points:

- During Module 1, you will understand the key aspects of Cardano's on-chain governance design.
- You will gain deep insight into the expectations and responsibilities of the DRep role and understand the relevance of delegation.

Continue to the “Cardano’s On-Chain Governance Design” section and explain the three pillars of Cardano's governance in the age of Voltaire:

1. Institutions
2. Constitutional representation
3. Democratic consent

At this point, highlight the importance of reading CIP-1694 to understand better the proposed governance system for Cardano, which will allow on-chain decision-making.

Continue with the lesson and introduce the five governance roles:

1. Delegate Representative (DRep)
2. Stake Pool Operator (SPO)
3. Constitutional Committee (CC)
4. Delegating ada Holders
5. Non-Delegating ada Holders

Understanding these roles may be challenging. A suggested approach to allowing participants a more profound understanding is to use the “students-produced question” approach. Asking questions is challenging, and participants can do deep thinking and learning by developing questions ([Franke et al., 2009](https://journals.sagepub.com/doi/abs/10.1177/0022487109339906)). Instead of asking participants questions about the roles to check if they understand them, encourage them to read the definitions and formulate their own questions about each role. This practice engages participants' working and long-term memory ([Arnold, 1984](https://www.taylorfrancis.com/books/mono/10.4324/9780203781197/memory-brain-magda-arnold)).

After presenting the governance roles, briefly describe the processes attained to each role. Point out that the support tools for each role will be explained later.

Finally, explain the overall governance action enactment process. Recall that CIP-1694 describes seven types of governance actions that can be proposed by ada holders and voted by the governance roles with voting rights (DRep, SPO, and CC member).

As a proposed engagement strategy, you can create groups representing each role with voting rights and simulate voting under different scenarios using flashcards or sticky notes to record votes.

Ensure there are no pending questions before moving on to the next activity.

**Activity 5: The DRep Role (20 min)**

In this activity, participants will review the definition of the DRep role. Jump to “The DRep Role” section in the training slides and discuss the responsibilities and expectations of a DRep. Point out the importance of a DRep as the collective voice of the ada holders that a DRep represents.

To better understand the DRep role, facilitate a discussion between the participants by asking the following questions:

1. How would you describe the DRep to a newcomer to Cardano?
2. What are the main challenges a DRep can face?
3. As a DRep, how would you deal with a conflict of interest when voting on a governance action?

There are no right or wrong answers to these questions; they are intended to foster collaboration between participants. Feel free to add or modify questions at your discretion.

Ensure there are no pending questions before moving on to the next activity.

**Activity 6: Understanding Delegation (20 min)**
In this activity, participants will learn about the importance of delegation and how it works. Move into the “Understanding Delegation” section on the training slides and start by fostering a critical thinking dialogue between the participants using [The Socratic Method](https://tilt.colostate.edu/the-socratic-method/).

This method involves a shared dialogue between teacher and students in a classroom setup. The teacher leads by posing thought-provoking questions. Students actively engage by asking questions of their own. The discussion goes back and forth.

You can start the discussion by posing questions, such as:

- What do you understand as “delegation” in Cardano’s ecosystem context?
- Are you familiar with delegation outside of Cardano’s ecosystem?

There are no right or wrong answers. The idea is to check participants' pulse around the meaning of delegation to set a baseline before explaining why delegation is important in the context of Cardano’s Governance.

Explain why delegation is necessary and how it is used in several liquid democracy applications.

Next, under the context of delegating voting rights to DReps, check participants' pulse on the following questions:

- Why not direct voting instead of delegation?
- Does delegation help?

Figure out scenarios that can illustrate the rationing proposed in the slides.

When the discussion ends, ensure there are no pending questions before moving on to the next activity.

Module 1: Cardano’s Governance and Roles

**Activity 7: Navigating the Code of Conduct (60 min)**

This activity focuses on understanding the DRep’s code of conduct to understand the ethical principles and behavioral expectations outlined in the Code of Conduct for DReps, focusing on guarding against malicious behavior.

For this activity, explain to participants that they will work in groups to analyze and discuss the code of conduct.

Divide participants into small groups of 3-5 members each and provide participants access to the [DRep Code of Conduct](https://docs.google.com/document/d/1uyCOzWO9uk71GRlCv_UT08Rt3kGBQMXFDXF3iiXejjU/edit#heading=h.qz1ffb3al08i). In an online session, you can create groups using breakout rooms in [Google Meet](https://support.google.com/meet/answer/13054147) or [Zoom](https://www.zoom.com/en/products/virtual-meetings/features/breakout-rooms/). Also, if you are conducting an in-person session, you can provide paper copies of this document.

Before having the groups discuss the code of conduct, explain the following instructions:

1. Explain the objective of the activity: to analyze the Code of Conduct and identify fundamental ethical principles and behavioral expectations that guard against malicious behavior from DReps.
2. Allocate 15 minutes for each group to read the Code of Conduct and discuss its contents. Encourage participants to highlight any sections that they find particularly relevant to prevent malicious behavior.
3. After the reading period, provide each group with flipchart paper and markers. You can use a shared online document, such as Google Docs, for online sessions.
4. Instruct groups to visually represent the fundamental ethical principles and behavioral expectations identified in the Code of Conduct. They can use diagrams, charts, or illustrations to depict these concepts.
5. Encourage groups to discuss and debate their interpretations of the Code of Conduct, considering different perspectives and potential scenarios where ethical principles may be tested.
6. Allocate 20 minutes for groups to work on their visual representations.
7. After the allotted time, ask each group to present their visual representation to the rest of the class. Allow time for questions and discussion following each presentation.
8. Facilitate a whole-group discussion on the insights gained from the activity. Prompt participants to reflect on the importance of ethical behavior in preventing malicious actions by DReps and how the Code of Conduct serves as a guide for upholding these standards.
9. Conclude the activity by emphasizing the role of DReps in promoting a culture of integrity and accountability.

Thank participants for their engagement and participation in the activity. Before proceeding to the next activity, ensure there are no pending questions.

Module 2: DRep Code of Conduct

**Activity 8: Reflecting on DReps Compensation (40 min)**

This activity focuses on discussing with participants if DReps should be compensated for their collaboration. Compensation for DReps is still an ongoing debate, so having insights from participants will enrich the rationale behind compensation.

Start by presenting the proposed reward schemes to the participants using the training slides that outline the different reward structures, incentives, and criteria for DReps. Ensure that the presentation is clear, concise, and easy to understand.

Divide participants into small groups, ideally consisting of diverse perspectives and backgrounds. Each group should be allowed to discuss the proposed reward schemes amongst themselves. Encourage participants to consider each scheme's potential benefits and drawbacks and any concerns or questions they may have. You can slot 10 to 15 minutes for this discussion.

After the group discussions, reconvene as a whole group for a structured feedback session. Each group can designate a spokesperson to summarize their discussion and present feedback on the proposed reward schemes. Facilitate a discussion where participants can share their insights, ask questions, and provide constructive feedback.

Document the participants' feedback during the session and ensure that it is compiled and shared with relevant stakeholders for consideration. Consider organizing follow-up sessions or opportunities for further discussion to address any outstanding questions or concerns raised by participants.

Thank participants for their engagement and participation in the activity. Before proceeding to the next activity, ensure there are no pending questions.

**Activity 9: DRep Reward Schemes (40 min)**

This activity focuses on explaining three variants of reward schemes. Similar to the previous activity, present the three variations of reward schemes and divide participants into small discussion groups. You can slot 20 minutes for discussion.

Following the group discussions, gather the entire group for a structured feedback session. Each group should nominate a spokesperson to recap their conversation and offer feedback on the proposed variants for reward schemes. Encourage an open discussion where participants exchange insights, pose inquiries, and provide constructive input.

Record the feedback provided by participants during the session, ensuring it is consolidated and distributed to pertinent stakeholders for review.

Congratulate participants for their active engagement in the activity. Ensure all questions have been addressed comprehensively before transitioning to the next segment.

Module 3: Reward Schemes for DReps

**Activity 10: How to Become a DRep (60 min)**
This is a hands-on activity in which participants will learn how to become a DRep through a demonstration.

As an instructor, you will lead participants using the GovTool to follow the required steps to join as a DRep.

The GovTool is currently being updated, so stay tuned for updates on this activity to learn more about conducting the demonstration.

**Activity 11: Engaging with the Community as a DRep (15 min)**

Communication is crucial to becoming an impactful DRep, so in this activity, participants will learn the available communication channels and tools that DReps can use to engage with the Cardano Community.

In this section, showcase the current channels and tools available:

- GovTool
- DRep Campaign Platform
- Cardano Forum
- Social Media

Ensure participants understand how to use these resources before continuing to the next activity.

Module 4: Joining the DReps Ecosystem

**Activity 12: Conclusions and Further Steps (20 min)**

This final activity aims to allow participants to reflect on their learning and consolidate key takeaways from the training day.

You can follow the next steps to conduct a final wrap-up activity:

1. Recap the main topics covered throughout the training day, highlighting key concepts and insights related to Cardano Governance design, Governance Roles, and the process of becoming a DRep.
2. Divide participants into small groups, ensuring a mix of individuals with varying familiarity with the subject matter.
3. Distribute sticky notes and markers to each group. Use breakout rooms and a shared board with notes like Miro, Ideaflip, or Mural in an online training session.
4. Prompt participants to reflect individually on the following questions:
- What was the most valuable insight or concept you learned today?
- How do you plan to apply this knowledge in your role as a DRep or within your organization?
- Is there any aspect of the training you would like to explore or have additional questions about?
5. Encourage participants to write their responses on sticky notes (or a shared board in online sessions), capturing each response on a separate note.
6. Once participants have had time to reflect individually, reconvene as a whole group.
7. Invite each group to share their reflections by sticking their notes on the whiteboard or flipchart under the corresponding question.
8. Facilitate a discussion around the shared reflections, allowing participants to elaborate on their responses and engage in dialogue with one another.
9. Summarize the main themes and insights from the discussion, highlighting any common 

challenges, opportunities, or areas of interest.
Close the session by expressing appreciation for participants' active participation and contributions throughout the training day. Reinforce the importance of ongoing learning and collaboration in the context of Cardano Governance.

Closing Activity and Wrap Up

DRep Pioneer Program

**Voltaire GovTool**

- [SanchoNet GovTool beta site](https://sanchogov.tools/)

- [Voltaire GovTool on Preview](https://preview.gov.tools/)

- [Voltaire GovTool on Mainnet](https://gov.tools/)

- [SanchoNet documentation site](https://docs.sanchogov.tools/)

- [Voltaire documentation site](https://docs.gov.tools/)

- [GovTool Repository](https://github.com/IntersectMBO/govtool)

**Node**

- [Latest node releases](https://github.com/IntersectMBO/cardano-node/releases)

**Ledger**

- [CIP-1694 | A first step towards on-chain decentralized governance](https://github.com/cardano-foundation/CIPs/blob/master/CIP-1694/README.md)
- [Conway design CDDL](https://github.com/IntersectMBO/cardano-ledger/blob/master/eras/conway/impl/cddl-files/conway.cddl)
- [Conway ledger backlog](https://github.com/IntersectMBO/cardano-ledger/issues?q=is%3Aissue+is%3Aopen+label%3Aconway)

**DB Sync**

- [Cardano DB-Sync 13.4.0.0](https://github.com/IntersectMBO/cardano-db-sync/releases/tag/13.4.0.0)
- [Note on naming scheme](https://gist.github.com/kderme/2ab2f79fcdc159be3465bae9b7df78e7)
- [Blog post on speeding up DB-Sync](https://github.com/IntersectMBO/cardano-db-sync/blob/blog/blog/blog.pdf)

**Wallets/CIP-95**

CIP-95 is the governance extension to the CIP-30 wallet-DApp bridge. For list of supported wallets please check [docs.sanchogov.tools](https://docs.sanchogov.tools/how-to-use-the-govtool/getting-started/get-a-compatible-wallet).

- [CIP-0095 | Web-wallet bridge – governance](https://github.com/cardano-foundation/CIPs/blob/master/CIP-0095/README.md)
- [demos CIP-95 test DApp hosted](https://ryun1.github.io/cip95-cardano-wallet-connector/)
- [demos DApp source code](https://github.com/Ryun1/cip95-cardano-wallet-connector)
- [demos CIP-95 prototype wallet](https://github.com/Ryun1/cip95-demos-wallet)
- [demos CIP-95 wallet build](https://drive.google.com/file/d/1751xFA1TSN7taNs2blTMeFwE6-xL3wKt/)
- [CIP-0105 | Conway era key chains for HD wallets](https://github.com/cardano-foundation/CIPs/blob/master/CIP-0105/README.md)

**Cardano Serialization Library (Conway beta) - Emurgo**

This is an Alpha build and the team are keen to hear feedback via [Github Issues](https://github.com/Emurgo/cardano-serialization-lib/issues).

- https://www.npmjs.com/package/@emurgo/cardano-serialization-lib-browser/v/12.0.0-beta.2
- https://www.npmjs.com/package/@emurgo/cardano-serialization-lib-nodejs/v/12.0.0-beta.2
- https://www.npmjs.com/package/@emurgo/cardano-serialization-lib-asmjs/v/12.0.0-beta.2
- https://crates.io/crates/cardano-serialization-lib/12.0.0-beta.2

**Cardano SDK**

[Cardano SDK](https://github.com/input-output-hk/cardano-js-sdk) is a comprehensive suite of Typescript packages suitable for both Node.js and browser-based development, used by [Lace](https://www.lace.io/) at its core for everything relating to the Cardano blockchain.

The [core/Serialization](https://github.com/input-output-hk/cardano-js-sdk/tree/master/packages/core/src/Serialization) package has support for serialization and deserialization, developed from the ground up in Typescript.

- https://www.npmjs.com/package/@cardano-sdk/core
- [Usage examples](https://github.com/input-output-hk/cardano-js-sdk/tree/master/packages/core/test/Serialization)

**Governance Metadata Standards**
The Conway ledger era ushers in on-chain governance for Cardano via [CIP-1694 | A First Step Towards On-Chain Decentralized Governance](https://github.com/cardano-foundation/CIPs/blob/master/CIP-1694/README.md), with the addition of many new on-chain governance artifacts. Some of these artifacts support the linking off-chain metadata, as a way to provide context.

There have been three governance metadata standards developed, so far, to define what the off-chain contextual data can look like.

- [CIP-100 | Governance Metadata](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0100) Base standard, providing a framework for future more specific standards.
- [CIP-108 | Governance Metadata - Governance actions](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0108) This proposal aims to provide a specification for off-chain metadata vocabulary that can be used to give context to governance actions.
- [CIP-119 | Governance Metadata - DReps](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0119) This proposal aims to provide a specification for off-chain metadata vocabulary that can be used to give context to CIP-100 for DRep registration and updates.

Two further standard is around the technical form of the constitution.

- [CIP-0120 | Constitution specification](https://github.com/cardano-foundation/CIPs/pull/796) This proposal aims to describe a standardized technical form for the Cardano constitution. Hoping to enhance the accessibility and safety of the document.
- [CIP-???? | Governance metadata - Constitutional Committee vote rationale](https://github.com/cardano-foundation/CIPs/pull/878) This proposal aims to provide a specification for off-chain metadata vocabulary that can be used to give context to constitutional committee votes.

**Built by the community**
Disclaimer: These tools and guides are created by the community and are not supported directly. Please refer any issues to the author.

**Tools from the community:**

- [Blockfrost.io](https://blockfrost.io/): the leading Cardano API-as-a-Service, which also provides access to the SanchoNet testing network.
- [NuFi Wallet CIP-95/ SanchoNet Compatible Build](https://blockfrost.io/): the first community CIP-95 wallet build.
- [Ogmios Conway Releases](https://github.com/CardanoSolutions/ogmios/releases): is a lightweight bridge interface for cardano-node. It provides an HTTP / WebSocket API that enables applications to interact with a local cardano-node via JSON+RPC-2.0.
- [Cardano-Signer](https://github.com/gitmachtl/cardano-signer): Open-Source multifunction tool, which can sign&verify data. Can also be used for Key-Generation, like dRep-Keys, CCM-Cold/Hot-Keys with Mnemonic-Support.
- [SPO Scripts](https://github.com/gitmachtl/scripts): Open-Source collection of CLI-Scripts to perform all kinds of transactions, key-generation, etc. on the CLI. Now with full Conway Governance support.
- [Adanordic.com](https://adanordic.com/): A work-in-progress rudimentary governance related explorer.
- [Cardano Multiplatform Library](https://github.com/cardano-foundation/cardano-wallet/releases/tag/v2024-03-01) A standard multifunctional library for serialization & deserialization of core data structures and useful utility functions.
- [Cexplorer.io SanchoNet](https://sancho.cexplorer.io/): The biggest and oldest Cardano explorer, supporting the SanchoNet testing network.
- [cardano-wallet Conway release](https://github.com/cardano-foundation/cardano-wallet/releases/tag/v2024-03-01): Cardano wallet is command line based software wallet.
- [drep.tools](https://drep.tools/): A very early version of a site to help DReps.
- [Plutarch](https://github.com/Plutonomicon/plutarch-plutus): A Haskell eDSL designed for writing fast and fine-tunable on-chain scripts. Currently supports PlutusLedger V1 and V2, with [V3 on its way](https://github.com/Plutonomicon/plutarch-plutus/issues/655).
- [carp 3.2.0](https://github.com/dcSpark/carp/releases/tag/3.2.0) This project is designed to sync data from the Cardano blockchain and store it into a Postgres database.
- [Parameter Proposal Guardrails Checker](http://ec2-16-171-11-232.eu-north-1.compute.amazonaws.com:8080/) The Parameter Proposal Guardrails Checker is a web-based tool that checks the constitutionality of a Parameter Update Proposal. It implements checks for the guardrails from the [Constitution](https://raw.githubusercontent.com/IntersectMBO/interim-constitution/main/cardano-constitution-0.txt).

**Guides from the community:**
![](https://media.discordapp.net/attachments/1095620786674466857/1281683207653163018/image.png?ex=66dc9c01&is=66db4a81&hm=fb1714eb0bebc3c5abbde8807c73243b5f28349a037b3d037352ed487163f08e&=&format=webp&quality=lossless&width=820&height=223)

[Sancho Panza: Navigating Cardano's Testnet Frontier](https://www.youtube.com/watch?v=9CR8c9ZIVEE)
[Sancho Testnet Guides and Command Line Interface](https://www.youtube.com/playlist?list=PLWYf5eQbRdbWa5n21tyy8xWpTS6zjm3Mj)
[How to become a delegated representative (DRep) on SanchoNet](https://www.youtube.com/watch?si=-i1zird99sNdnDKq&v=frkgK1VGhZU&feature=youtu.be)

Tools and resources

**Warning**: Please note that due to ongoing development, some answers may change over time.

*Last update: 2024-02-17*

Based on ledger design cddl: node 8.8.0-pre

1. **What are the new Conway certificates?**
![](https://media.discordapp.net/attachments/1095620786674466857/1281685496136863835/image.png?ex=66dc9e22&is=66db4ca2&hm=a57401b9836c8d1db74932014ebcfa469a884c595e5b8cde3439877874992df9&=&format=webp&quality=lossless&width=680&height=616)

2. **Why are there two ways to register/unregister stake credentials now?**
![](https://media.discordapp.net/attachments/1095620786674466857/1281686178130694195/image.png?ex=66dc9ec5&is=66db4d45&hm=4af66a818a9a1fd722f5062fd3abf5009e32f763d183f2bacc31423ea28b546f&=&format=webp&quality=lossless&width=820&height=62)

The new version allows the ledger to check deposit amounts and return them instantly (rather than on epoch boundary), matching the other new certificates containing deposits.

3. **Why do new certificates have a `coin` field?**
This change has been made to enable the checking of deposit amounts at the ledger level. It also proves to be more useful in Voltaire, given that protocol parameters are likely to change more frequently than in past eras.

4. **Certificate and transaction field witnesses and deposits**
![](https://media.discordapp.net/attachments/1095620786674466857/1281687063330033745/image.png?ex=66dc9f98&is=66db4e18&hm=bc03e223e4b6836c019f4e55e522b566d9a63b287390a6c8359df6de56f22ec8&=&format=webp&quality=lossless&width=684&height=616) 
![](https://media.discordapp.net/attachments/1095620786674466857/1281687426301034617/image.png?ex=66dc9fef&is=66db4e6f&hm=92d26373efc80917af02ce2a036538f12a584f34500430766b525d48a2a826bf&=&format=webp&quality=lossless&width=711&height=616)
![](https://media.discordapp.net/attachments/1095620786674466857/1281687637551349925/image.png?ex=66dca021&is=66db4ea1&hm=4192dc4f19dfcf10d54d589129ac21db3911943a07342d987f5af79c27853307&=&format=webp&quality=lossless&width=820&height=316)

5. **Why isn't the script directly included in a new constitution proposal for the proposal policy?**

The decision to provide only the script hash, rather than the entire script, within a new constitution proposal serves the purpose of reusing the mechanisms previously implemented in Babbage. For instance, it allows individuals to use reference scripts to provide the actual script for the proposal policy when proposing various governance actions. Creating another source for scripts would entail more work.

6. **Regarding the proposal policy for a new CC constitution action: How does the proposal policy script impact the script integrity hash in the transaction body? Do I need to consider the cost model of the provided script?**

The new constitution proposal contains a `ScriptHash`, also known as the proposal policy. There is nothing special that needs to be done during the proposal stage because the policy is simply being suggested. The significance comes into play when a new constitution with a script hash (proposal policy) is enacted. At that point, the constitution will require scripts and redeemers for every governance proposal, except for the `new_constitution` and `no_confidence` proposals. In these cases, it will function in a manner similar to other scripts.

7. **If a voting proposal requires a script and a redeemer, which redeemer tag should I use?**

This tag is yet to be implemented. The designated tag for such instances will be 5, with the index in the redeemer corresponding to the proposal procedure. Additionally, there will be tag 4 – specifically for voting procedures.

8. **What will be the maximum number of protocol parameter changes that can be executed in a single governance action?**

With numerous Plutus versions having distinct cost models, accommodating all of them may become impractical. Nevertheless, it's highly unlikely to exceed the maximum transaction size in the near future.

9. **Can one delegate to DReps that do not exist?**

There are no checks for this at the ledger level, neither for SPOs nor for DReps. At any point, the DRep and the SPO to whom you delegated can unregister, so there is no need to enforce their existence when delegating.

10. **Is it possible to stake a DRep deposit when it is locked?**

No, there is no mechanism to facilitate that action. The purpose of the deposit is to restrict the use of those funds.

11. **What happens with DRep deposits when no stake credential is provided, and where is the deposit returned?**

DRep deposits function similarly to stake credential deposits. They are refunded in the transaction that unregisters the DRep. Stake pool and proposal procedures are retired or expired on the epoch boundary, which is why their deposits are refunded into a reward account. However, DReps and stake credentials are unregistered immediately.

13. **Does the new donation field function similarly to implicit outputs?**

Donations function more like fees. They are collected in a pool and then transferred at the epoch boundary.

14. **How does the 'current treasury value' function, and what happens if I set it to an incorrect value?**

The 'current treasury value' is used for conveying the current treasury amount to Plutus scripts. If the treasury field is set incorrectly, the transaction will be rejected.

15. **How does the process of CC resignation (resign_committee_cold_cert) work, and what happens if all CC members resign? Does this impact the quorum?**

Resigned and expired constitutional committee members are automatically counted as if they have voted 'Abstain'.

Another crucial point to note is that whenever the number of active committee members (those who are neither expired nor resigned) falls below the `committeeMinSize` protocol parameter, the system enters a mode in which it is as though all committee members have cast a 'No' vote.

16. **For `parameter_change_action` and `treasury_withdrawals_action` does the optionally supplied `policy_hash` require a witness from the script?**

Yes. It is only optional, when there is no governance policy. When there is a governance policy we require that `policy_hash` to be present and equal to the one in the elected constitution.

17. **Are the governance voting threshold Parameters set to be fixed at 2 decimal places?**

No, they are rational numbers on the unit interval where both numerator and denominator are specified by 64bit unsigned integers. So, those thresholds can be very precise.

18. **Do unwithdrawn staking rewards count towards one's voting power/ is counted in active/inactive voting stake amounts?**

Yes, the amount in the reward account is counted towards active stake, which means it will also participate in the voting. This decision was to prevent people from constantly withdrawing rewards just so they can get rewards on that amount.

19. **Do any locked deposits count towards voting stake?**

The only deposits which count toward voting stake thresholds are deposits locked for governance actions.

Conway ledger era FAQs

**Instructions**

1. Join the IOG Discord community: https://discord.gg/p3jYKGxMvE
2. Complete the captcha verification
3. In #start-here, select 'Join the SanchoNet Community'

The 'Voltaire' category, containing SanchoNet channels, will appear. You can enter these channels and join the discussion or just follow along!

**SanchoNet Discord channels**

The SanchoNet channels include the following:

- #announcements for updates about SanchoNet
- #spo-sanchonet for SPO discussion
- #drep-sanchonet for DRep discussion
- #builder-sanchonet for discussion of SanchoNet community tooling and infrastructure projects
- #wallets-sanchonet for wallet discussions, SanchoNet and [CIP-95](https://github.com/cardano-foundation/CIPs/blob/master/CIP-0095/README.md)
- #govtool-sanchonet for discussion of [Sancho GovTool beta](https://sanchogov.tools/)
- #live-sancho for live sancho calls

Join the community

SanchoNet meetups is a way for people to get to know more about SanchoNet be it online or offline at an event.

This page can be updated by anyone in the community by submitting a pull request with changes.

![](https://media.discordapp.net/attachments/1095620786674466857/1281690081425358848/image.png?ex=66dca268&is=66db50e8&hm=dde6f823d4c845d3e8d05d8b5e02609a426f708b5a3ca7167b5a3c2eb3f5911e&=&format=webp&quality=lossless&width=820&height=284)

- **Location** 
Norway

- **Date**
12. Nov 2023

- **Link**
https://www.meetup.com/cardano-blockchain-oslo-no/events/296420885/

- **Info**
SPO workshop hosted by NADA, https://twitter.com/NordicADA


- **Discord(Online)**
Every Thursdays 8:00PM EST = (GMT-5)

- **Link**
https://discord.gg/tHYrxCtdHm

- **Info**
SanchoNet CLI workshops for DReps hosted by Mike Hornan[ABLE]

Meetups

SanchoNet is the testnet for rolling out groundbreaking governance features for the Cardano blockchain, aligning with the comprehensive CIP-1694 specifications. SanchoNet stands apart from other testnets; it's a vibrant, inclusive, and community-driven platform. Every community member is invited to join SanchoNet and actively contribute to shaping Cardano's governance future.

Welcome to SanchoNet - your gateway to Cardano's governance future!

SanchoNet

Course Details

Level

Ratings

Modules

Lessons

Holder $WORK Price

Contact Us

Documentation

Navigation