# ⚠️ GovTool Maintenance Ending Soon GovTool Maintenance Ending Soon. Without new support, active development and maintenance will end in June 2025. Learn what this means and what’s next ## Key Links * 👉🏻 [The future of GovTool: Why it matters and what comes next](/important-updates/govtool-maintenance-ending-soon/the-future-of-govtool-why-it-matters-and-what-comes-next) * 👉🏻 📑 Budget Proposals * [Original Govtool Budget Proposal](https://gov.tools/budget_discussion/552) (*submitted on 22nd April 2025*) * Updated Govtool Budget Proposal * [Short version](/important-updates/govtool-maintenance-ending-soon/updated-budget-proposal/updated-govtool-budget-proposal-short-version) * [Full detailed version](https://docs.google.com/document/d/15L7uA2PWeOBuQCnoGg0ZB35acvxreJ2QCMAkt9X8o1E/edit?tab=t.4qjaum32z5qp) (Open google doc for feedback and refinement) * 👉🏻 [GovTool - a breakdown of the costs so far](/important-updates/govtool-maintenance-ending-soon/govtool-a-breakdown-of-the-costs-so-far) * 👉🏻 [Govtool open Analytics ](https://analytics.gov.tools/) # The future of GovTool: Why it matters and what comes next Cardano has entered a new chapter, a new dawn. With the implementation of [CIP-1694](https://www.1694.io/en) and the dawn of the [Voltaire era](https://roadmap.cardano.org/en/voltaire/), the community now has the power to shape the network’s future through on-chain governance. But power without access is meaningless. Participation in governance depends not just on protocol, but on accessibility. [GovTool](https://gov.tools/) was created to make Cardano’s governance system truly accessible and for the benefit of the public. It offers a simple, open source, non-commercial experience that empowers anyone in the ecosystem to participate directly. In the most recent budget round, however, the proposal to continue funding its active development did not receive enough support from the DReps. In this post, we’ll explore what GovTool is, why that decision matters, and what comes next. ## Why Cardano needs a tool like GovTool Cardano’s governance model aims to be decentralized, transparent, and community-driven. But to achieve that vision, it must also be inclusive. Most ada holders are not blockchain engineers or protocol experts. Without an easy way to engage, their voices risk being excluded from the decision-making process. GovTool fills this gap. It enables ada holders to [register](https://docs.gov.tools/cardano-govtool/faqs/what-does-it-mean-to-register-as-a-drep) as Delegated Representatives (DReps), [view and delegate](https://gov.tools/drep_directory) to a DRep, view all [proposed Governance Actions](https://gov.tools/proposal_discussion), [vote on proposals](https://gov.tools/governance_actions), [submit new](https://docs.gov.tools/cardano-govtool/using-govtool/governance-actions) Governance Actions, and [review results](https://gov.tools/outcomes?sort=newestFirst), all through a clean and intuitive interface. More than that, it’s community-owned, fully [open-source](https://github.com/IntersectMBO/govtool/), and deliberately non-commercial. Its purpose is to serve the ecosystem, not profit from it. It provides the broader Cardano community with: * Reduced technical barriers - no need for CLI knowledge or custom wallet scripts to participate in governance. * Encouraging broader participation - gives non-technical users a way to register, delegate, vote, and propose with confidence. * Strengthening governance legitimacy - the more inclusive the participation, the stronger and more credible the outcomes. * Preventing fragmentation - provides a single, unified experience across governance functions, rather than scattering them across third-party tools. * Enabling safe experimentation - the platform supports users in practicing before taking actions on the mainnet by providing access to the Cardano preview and pre-prod networks. * A basis for community development – by exposing stable APIs, the platform provides an easy way for developers to create their user interfaces or integrate governance into their applications. Without a neutral, public-good platform like GovTool, we risk fragmenting participation or worse, privatizing it. And when governance participation becomes a product rather than a right, decentralization begins to break down. ## What GovTool offers GovTool is often mistakenly seen as simply a user interface, but it plays a much deeper role. It functions as both a practical interface and an enabler of broader participation, acting as a connective layer between tools and networks across Cardano governance. Users can engage with the entire governance process through GovTool, from registering as a [DRep](https://gov.tools/drep_directory) or Direct Voter to delegating voting power, submitting proposals, casting votes, and tracking outcomes. The experience is intentionally designed to lower technical barriers and make participation straightforward at every stage. Beyond the user-facing features, GovTool offers open APIs that are actively utilized by projects across the ecosystem, not only to integrate with the governance process but also as a flexible foundation for innovation. These APIs enable community developers to build upon GovTool, extend its capabilities, fork it entirely, or create entirely new interfaces for governance participation, thereby lowering the barrier to entry for both toolmakers and users. It supports governance activity on [Preview](https://preview.gov.tools), [Preprod](https://pre-prod.gov.tools), and [Mainnet](https://gov.tools), enabling users to safely test and practice actions before committing them on-chain. This multi-network compatibility has been vital for onboarding new participants and supporting safe, iterative engagement.\ \ With an open design system, [transparent analytics](https://analytics.gov.tools/), and a [maintained testing framework](https://intersectmbo.github.io/govtool-test-reports/), GovTool is far more than a frontend. It’s a foundational platform that underpins Cardano’s move toward inclusive, accessible, and robust decentralized governance. ## A community-built foundation GovTool was not built by a single entity or developed with commercial interests in mind. It was created by a distributed group of contributors and coordinated through the Governance Tools Working Group. This community-led approach has allowed GovTool to grow in lockstep with the governance process itself, from early experiments on SanchoNet to full-featured proposal submission and voting support on mainnet. At every stage, the focus has been on serving the community. Feedback has directly informed improvements to clarity, usability, and feature coverage. Recent updates have included enhanced proposal browsing, more detailed governance outcome displays, and expanded support for constitutional amendments, motions of no confidence, and budget proposals, all shaped by real user needs. ## Why the funding vote didn’t pass In the latest budget cycle, GovTool’s funding proposal was not approved by the DReps. Some found the original budget too high. Others were unaware of the tool’s deeper value or misunderstood its scope. A few raised concerns about the user experience or questioned whether a single tool should be responsible for such a significant portion of the governance process. These concerns were heard – and they’re being acted on. A revised proposal is now in development, featuring a tighter scope, reduced costs, and a more precise articulation of its value to both users and builders within the ecosystem. The goal is to maintain and improve what already works while addressing concerns and building trust. ## The risk of losing GovTool It’s important to clarify: GovTool will not vanish immediately without funding.\ \ As open-source software, it will remain available. But without active maintenance, it will fall behind, especially as the Cardano protocol continues to evolve. Bug fixes, new feature support, and critical integrations will stall, and we will have to rely on individual contributors acting as volunteers to keep the project moving forward. More seriously, other projects that rely on GovTool’s APIs and backend infrastructure may lose key functionality. DReps and Direct Voters could find themselves forced to rely on more fragmented, less open tools. New users, who might otherwise have joined the governance process, could be discouraged by technical barriers or inconsistencies between platforms. A unified experience matters. It lowers the barrier to entry, builds trust, and helps drive broader participation. Fragmentation, by contrast, risks making Cardano governance something only a few can engage in meaningfully. ## Where we go from here The teams behind GovTool are not giving up. A new proposal is being drafted that significantly reduces the original funding request while still securing the future of the tool. In the weeks ahead, we’ll be hosting open forums, gathering feedback, publishing testimonials from ecosystem projects that rely on GovTool, and implementing updates that directly address user concerns. The revised proposal will reflect both the lessons of the last vote and the values of the Cardano community. To ensure continuity while the community considers the new proposal, Intersect has committed to keeping GovTool available and functional through the end of 2025. This temporary bridge will give the ecosystem the time it needs to evaluate and support a long-term solution. The next vote will not be a repeat, it will be a reboot! ## How you can help If you believe in open, inclusive, decentralized governance, your support matters. You can help GovTool continue to serve the Cardano community by: * Sharing this blog with your peers and networks * Joining upcoming discussions and X Spaces * Helping correct misconceptions when you hear them * Supporting the revised proposal when it is submitted. \+ If you’re a DRep, your vote has an impact. If you’re a builder, your voice helps shape the message. And if you’re an ada holder, this is your governance too - make sure your DRep intends to vote according to your wishes. ## Govtool – Cardano’s governance enabler GovTool is more than a tool; it provides a core foundation component for how Cardano governs itself. It ensures that governance remains in the hands of the many, not the few. It invites collaboration, encourages transparency, and reduces barriers to meaningful participation. Whether you're a voter, a developer, a builder, or simply someone who cares about Cardano’s future, GovTool is part of your story. With your support, we can maintain an open governance approach, ensuring the continuity of decentralized governance on Cardano.
# Updated Budget Proposal # Updated Govtool Budget Proposal - short version This is a short and concise version of a longer more detailed version {% hint style="danger" %} **FULL DETAILED PROPOSAL** 👉🏻 You can read, comment and provide feedback on the full detailed proposal [here](https://docs.google.com/document/d/15L7uA2PWeOBuQCnoGg0ZB35acvxreJ2QCMAkt9X8o1E/edit?tab=t.4qjaum32z5qp) 👈 {% endhint %} {% hint style="info" %} You can listen to the key details of this proposal in [this podcast](https://drive.google.com/file/d/1HVtw7qYNDUNp577Rz2rTM8JxacvXZMD3/view?usp=sharing) {% endhint %} ## What are the key differences with the original proposal * More detailed breakdown of costs * More options to progress maintenance and development with a stronger community-led open-source strategy and a tiered approach * Flexibility to fund just repo maintenance or active development and maintenance of individual pillars * More data on usage so far, and direct access to analytics ## Why is Govtool needed and what happens if it’s not maintained Cardano’s governance framework gives the community real power over the network’s evolution, but power without access is meaningless. Most Ada holders aren’t developers with in-depth knowledge of all the wrinkles of the governance design. Without a shared, accessible interface, participation becomes limited, fragmented, or dependent on private platforms. GovTool solves this by providing a unified, open-source platform that lets anyone submit proposals, vote, delegate, and view results, no CLI or technical setup required. It supports Preview, Preprod, and Mainnet, ensuring users can safely learn and engage at every step. If GovTool isn’t maintained: * Users will need to rely on fragmented or commercial tools, undermining transparency and inclusiveness. * Essential governance functionality could stall or degrade as the protocol evolves. * Builders and projects that rely on GovTool’s APIs would lose critical infrastructure, slowing innovation. * Governance could become harder to access and more exclusive, the opposite of what Cardano stands for. GovTool is not just a UI, it’s a public digital infrastructure that safeguards decentralized governance as a right, not a privilege. ## What value has Govtool provided so far? GovTool has been foundational in enabling and scaling Cardano’s on-chain governance, delivering real-world functionality, infrastructure, and participation at a level no other tool currently matches: * It has enabled Thousands of DRep registration, delegations, and thousands of on-chain votes—all through a clear, accessible interface that abstracts protocol complexity. * Supported governance across SanchoNet, Preview, Preprod, and Mainnet, allowing users to learn and test safely before making real decisions. * Underpins the entire governance cycle: from discussion and proposal submission, to registration, delegation, voting, and reviewing final outcomes—in one consistent, guided user experience. * Powers a growing ecosystem of third-party tools and dashboards through its free, open APIs, used by platforms like[ 1694.io](https://1694.io),[ CardanoBudget.com](https://cardanobudget.com),[ Tempo.vote](https://tempo.vote), and more. * Built and maintained by a distributed community team (including DQuadrant, Byron Network, Lido Nation, Bloxico, and others), with full transparency and community direction via the Governance Tools Working Group. * It supported shaping the governance experience since before CIP-1694 was approved. * It supported the ecosystem to go through the bootstrapping phase, enabling the community to test governance, register as DReps and delegate. * It enabled the whole community to enact the first community-led hard-fork and gave everyone easy access to full governance, also allowing easy participation in the approval of the first Cardano Constitution. * Its modular architecture (Voting, Delegation, Proposals, Outcomes, and Budget Pillars) enables independent improvements and scaling, reducing maintenance complexity. * Provides end-to-end testing with Autonomous Agents, ensuring governance flows are reliable, scalable, and regression-tested with every protocol or feature update. * Offers transparent Matomo-based usage analytics, allowing the community to see how the tool is used and where engagement is growing. * Supports open-source design patterns and documentation, making it easier for new contributors and builders to adopt or fork components. * Acts as a reference implementation for governance workflows, enabling faster ecosystem-wide learning. * Includes unique governance UX features such as DRep directories, real-time voting status, rationale submission, and visibility into Constitutional Committee activity and voting thresholds. * Facilitates liquid democracy by enabling users to switch delegations easily and understand DRep behavior over time, supporting informed governance. * Plays a strategic role in education and onboarding—many first-time voters, delegators, and proposers have used GovTool to explore and participate in governance without technical expertise. * Enables pre-governance engagement, such as discussion threads, moderation tools, and eventually polling, making social consensus more transparent before on-chain actions are submitted. This enabled the first Cardano budget to gather alignment and support. In short, GovTool is more than a tool—it is a collaborative foundation for participatory governance in Cardano. It reduces technical friction, improves transparency, empowers builders, and reflects the principles of decentralization in both architecture and governance. ## Proposal costs The revised budget addresses community feedback with a modular, transparent structure that allows flexibility while ensuring core sustainability. ### Level 1 – Foundational ($330K / ₳412.5K) (2.25 FTEs in total + hosting costs) Covers minimum operational costs: * Infrastructure maintenance, hosting, CI/CD, and security. (0.25 FTE) * Core maintenance team (1 FTE QA and 1 FTE full-stack developer, split across 4 contributors to avoid downtime). * Ensures GovTool stays online, secure, and functional, but without guaranteed new features. ### Level 2 – Incentivised Participation ($530K / ₳662.5K) * All in Level 1 * **₳150,000** to be allocated organically via direct contribution on the repos * **₳100,000** to be allocated to other open source governance tools that provide new and better ways to participate in Cardano Governance leveraging (and where possible expanding) Govtool code or Govtool APIs Enables open contribution: * Introduces ada-based bounties for meaningful contributions. * Allows external sponsorship of specific roadmap features. * Supports GovTool’s organic, community-led development. ### Level 3 – Pillar Development & Active Maintenance ($920K / ₳1.15M) (level 1 costs + level 2 costs + active development and maintenance costs of the pillars // the costs varies depending on which and how many pillars are selected) Accelerates growth and guarantees monthly updates: * Funds full-time development per functional pillar: * Proposals Pillar (0.75 FTE) * Delegation Pillar (1 FTE) * Voting Pillar (1.25 FTE) * Outcomes Pillar (0.75 FTE) * Budget Discussions Pillar (0.5 FTE) * Adds dedicated end-to-end testing (1 FTE) to ensure reliability. * Modular: each pillar can be funded individually or as a full suite. Any unused funds will be returned to the Cardano Treasury, and the project will continue to be steered through the Governance Tools Working Group, maintaining open contribution pathways for new teams and community members. ## Why the Updated GovTool Proposal Costs Less * Original maintenance costs per each pillar were reviewed based on community and DRep feedback and then reduced * The costs of research and development for new features, which were budgeted separately in the original budget proposal, have been incorporated into the active maintenance costs in the revised proposal * A new tiered budget was introduced bringing a more balanced approach, where in particular the foundational tier brings savings by embracing fully the common open source project support \
# Updated Govtool Budget Proposal - long version Cardano’s open-source tool for the community to contribute to governance: Cardano Govtool {% hint style="info" %} you can read the short version [here](/important-updates/govtool-maintenance-ending-soon/updated-budget-proposal/updated-govtool-budget-proposal-short-version) or you can listen to the key details of this proposal in [this podcast](https://drive.google.com/file/d/1HVtw7qYNDUNp577Rz2rTM8JxacvXZMD3/view?usp=sharing) {% endhint %} Budget category: Governance Support ## Problem Statements and Proposal Benefits ### Problem Statement With the implementation of[ CIP-1694](https://www.1694.io/en) and the dawn of the[ Voltaire era](https://roadmap.cardano.org/en/voltaire/), the community now has the power to shape the network’s future through on-chain governance. **But power without access is meaningless**. **For on-chain governance to be effective, it requires *****participation***. To enable and facilitate meaningful participation, a simple and consolidated user experience is key to allow Ada holders, new and existing, to get informed, onboarded, delegate to DReps (or become DReps), discuss and create new governance actions, see/vote on governance actions,and see outcomes of the whole process. For the **public good**, it is also key for the Cardano community to own and maintain **a set of basic tools that will always be, open-source, non-commercialized and available/accessible to foster this participation** and so to keep decision making in Cardano ecosystem matters as fair, transparent and open as possible. Without an open-source solution, we risk the productization of participation. If the core governance tools become driven by profit, access and influence could become inequitable and shaped by those that can afford to maintain or fund development, without community input. This effectively undermines the ideals of decentralized governance. Based upon these unique risks, an open-source, community owned alternative must always exist. This ensures every ada holder has equal opportunity to participate. In this context, reliable and neutral governance tooling is not just helpful, it is essential. The community must have full confidence that the tools they rely on to participate in governance will always be available, open, and free from bias. Conversely, **a closed-source voting application, controlled by a single group or enterprise, introduces risk as participants cannot independently verify its integrity or fairness**. Without trusted, non-commercial, and unaffiliated tooling, decentralized governance loses its foundation. Just as in any democratic system, **if the infrastructure of participation is compromised, so too is the legitimacy of its outcomes**. #### **What happens if Cardano GovTool is not maintained?** **The absence of GovTool**, or a similar set of tools, **would make effective and collaborative governance dramatically harder, riskier, and less inclusive**. There is a chance of drastic reduction of participation and transparency, potentially caused by the privatization of governance tooling.. Here’s what would be lost or degraded: * **Barrier to participation in Governance would be higher**: Without GovTool (or a set of tools like GovTool), most actions needed to participate in governance (registering as a DRep, voting, proposing, etc.) would require use of the CLI, other technical tools, or any privately owned tool (that still needs funding). This would exclude the majority of Ada holders, particularly non-technical users who rely on the Web UI. * **Fragmentation and Inconsistency**: Governance is complex by nature, other tools may try to fill the gap, but the experience of inconsistency and fragmentation will become inevitable. It is a well known and tested and proven axiom of product design that simpler, integrated products make for greater participation. Fragmentation of this experience will reduce participation in real terms, making Governance an expert-only area. This is not in the spirit of Cardano, nor does it reflect the ideals of the Voltaire area. It is effectively a type of ‘voter suppression’. No single experience currently supports: * All governance action types * All Cardano networks (Preview, Preprod, Mainnet) * Full open-source contribution with test coverage and analytics * A unified experience combining discussion, submission, delegation, voting, and results * Free to use OpenAPIs * **Loss of Governance On-Ramps**: Without Preview and Preprod support, there would be no safe testing ground for new DReps or proposers to learn and build confidence before acting on Mainnet. * **Broken Ecosystem Integrations**: Projects that currently build on GovTool APIs or plan to, would lose their base infrastructure. This would stall innovation and delay community-driven tooling efforts. * **Reduced Transparency and Trust**: Other governance tools may be closed-source, lack visible roadmaps, or provide limited insight into their inner workings. GovTool's public analytics, code, backlog, and docs are a benchmark for accountability. Losing that would damage trust in governance tooling. * **Missed Opportunity for Decentralization**: GovTool is already moving toward a community-led bounty-based model. If abandoned, the Cardano community would miss the chance to create a sustainable, decentralized tooling system—and fall back into centralized or underfunded governance interfaces. In short, without Cardano GovTool, governance could become less transparent, less accessible, and more centralized. Preserving and improving Cardano GovTool is not just a maintenance task, it is a commitment to participative, inclusive, and decentralized governance for all Ada holders. ### Proposal Benefit Cardano GovTool, a set of open-source, community-owned governance tools, has been providing this support for open participation since before CIP-1694 was approved in 2023. #### **What did Cardano Govtool enable so far?** * It first fostered **adoption of wallet upgrading to the new governance standards** (CIP-95/CIP-105) with its first beta version * It acted as a **reference implementation for** what **Cardano governance tools** could look like * It fostered **testing and usage of SanchoNet**, with the SanchoNet GovTool (used by over 30k+ unique users), which helped iteration to get to the **bootstrapping phase of Cardano’s governance**. It allowed community practice and familiarise with governance by submitting and voting on governance actions, registering and delegating to DReps, and **informed improvements before mainnet launch**.\ During this time, the governance tools working group, and the teams and individuals building Govtool became a focal group for other builders to connect. * Since the Chang upgrade, **it opened participation during the bootstrapping phase of Governance**, helping grow the DRep pool and the total ada delegated to DReps, as well as making governance clear and visible to the community, also **allowing the first-ever community-led hardfork** to be decided transparently on-chain.\ As on-chain governance matured, GovTool expanded to support all types of Governance Actions. Initially, simpler proposal types like Info Actions (non-binding information proposals) and Treasury Withdrawals were enabled for submission via the UI. These were chosen first due to their relative simplicity and broad utility. By late 2024, GovTool could render all proposal types for voting, meaning DReps could view and vote on protocol parameter changes, constitutional amendments, etc., even if submission of some complex types was pending.\ During this time, the first set of tools that used Govtool backend APIs started to appear, providing new and different ways for the community to interact with governance. * Since the Plomin upgrade, it has been the key benchmark reference for Cardano Governance for the community, being at the forefront in solving new hard challenges, creating reference implementations, and setting standards, allowing other community tools to provide extended value via their interfaces. The Cardano Plomin upgrade fully enabled CIP-1694 on mainnet, including on-chain governance action submission for all types of governance action. This was a turning point: “full governance” was now live on mainnet, and **GovTool reached a key milestone of allowing users to experience end-to-end on-chain governance on both testnet and mainnet through a user-friendly interface**. By this time GovTool had versions 1.0.24+ with significant enhancements like support for CIP-1694 identifiers, treasury withdrawals, improved Ada formatting, and better voting power calculations. #### **What governance steps does Cardano Govtool support?** Outside of playing a crucial ecosystem role by keeping governance open and fair, Cardano GovTool does cover the full Cardano Governance process: 1. It **allows anyone to submit a proposal, discuss it, improve it** with community feedback, and **submit it as a Governance Action in an easy guided process** 2. It **allows Ada holders to register as DReps**, or as Direct Voters (a role introduced by GovTool to increase participation), via a step by step guided process, also allowing DReps to share their profile and campaign. Furthermore, it also allows DReps to retire when needed 3. It **allows Ada holders to view, review and compare all DReps** (tagging them appropriately if active, inactive or retired), **allocating and changing delegation** to them easily, **enabling true liquid democracy** 4. It allows DReps, and Direct Voters, to **review and vote on governance actions**, encouraging them to submit a rationale for their vote 5. It **allows anyone to review the outcomes of the governance actions** that have been submitted on-chain and easily understand the outcome and why that was the decision reached 6. Via the Constitutional committee Portal it allows anyone to **see and search the Cardano Constitution in an accessible format**, to **compare different versions and track changes to the Constitution**, as well as view Constitutional Committee members, their votes, and rationale. #### **What other value does GovTool provide?** In addition to its governance features and collaborative development model, GovTool offers unmatched infrastructure capabilities and openness that make it a foundational pillar of Cardano’s on-chain governance ecosystem. Here’s what sets Cardano GovTool apart: * **Multi-Network Support**: GovTool is the only governance tool that supports Cardano’s Preview, Preprod, and Mainnet networks. This tri-network support is critical not just for developers, but for inclusive governance participation: * Preview and Preprod allow anyone to practice governance, register as a DRep, delegate, vote, or submit proposals, without risking real ada. * These testnets are not “simulations” only; they are also active protocol testbeds where Governance Actions such as protocol parameter changes can be submitted and executed, making them essential for refining governance flows before Mainnet deployment. * To ensure reliability and quality GovTool operates as a multi-environment system spanning development, QA, and live networks across all governance pillars (Voting & Delegation, Proposal Discussion Forum/Budget Proposals, and Outcomes). Each pillar is deployed and maintained separately on Dev, QA, Preview, Preprod, and Mainnet, enabling continuous development, testing, and public use. * **Open APIs for All Builders**: GovTool exposes fully open, well-documented APIs for accessing governance metadata, proposals, voting data, and more. These APIs are free to use and are already powering multiple third-party tools across the ecosystem. This enables: * Builders to create specialized experiences, dashboards, or governance assistants on top of GovTool’s backend. * Ecosystem diversity by reducing dependency on centralized infrastructure. * A plug-and-play model for wallets, explorers, and other apps to add governance features effortlessly. * **Inclusive User Interface and Contribution Model**: * For non-technical users, GovTool offers a clean, Web2-like interface that abstracts blockchain complexity and empowers anyone to participate in governance. * For builders and contributors, GovTool is: * Fully open source, with the public GitHub repositories. * Extensively documented, including API specs, contribution guides, and governance context. * Equipped with publicly available test suites for transparency and validation. * Backed by a fully open development backlog, allowing the community to propose, discuss, and prioritize features together. * **Transparent and Accountable Operations**: * Matomo-based usage analytics are published openly, so the community can see exactly how GovTool is being used, by whom, when, and where. * GovTool is possibly the only Cardano governance tool using Autonomous Test Agents that test Governance actions according to CIP-1694, helping ensure higher reliability, regression testing, and performance under load. * The idea by one of the development teams was to create an automated testing tool (not available on Cardano) to be able to test at scale, reduce testnet time leading to timely delivery of GovTool on mainnet. This tool known as Autonomous Agent Testing is available as open source for the developer community as a result of the GovTool project and Catalyst funding for this idea. * **Full Governance Action Support (On the Way)**: While many tools visualize governance, GovTool is on track to become the only app that enables submission of all Governance Action types directly from the interface. Some of this is already live via backend, and full UI support is being actively developed. **GovTool’s architecture and transparency model create a unique value proposition**: it is not just a tool to use, it is an infrastructure layer that invites the entire community to build, extend, audit, and improve how Cardano governs itself. **Cardano Govtool has been and remains ****the only fully open-source****, ****fully community-owned set of tools**** to support the governing of Cardano without a commercial agenda**. Via community feedback and direct decision making via the open Governance Tools working group, it keeps evolving and improving, incubates opportunities for the whole ecosystem to participate and/or build on top of it. It provides access to a variety of API endpoints that do the heavy lifting for many new governance tools to exist and provide different ways to participate in governance. A set of truly community-owned tools to participate in the Government of our ecosystem, such as Cardano Govtool, is a critical and pivotal component of Cardano, **ensuring that regardless of individual tools' decisions and support, Cardano’s governance will always be transparent and easy to access**, encouraging fair and distributed governance. In short, Cardano Govtool is like a public square where the Cardano community joins effort in defining and improving their experience for a simpler, more open and transparent government, where hard challenges get solved with the shared expertise of our ecosystem and where consolidated effort enables smaller individual contributors to multiply the value provided to the whole community. Furthermore, this joint effort removes the heavy lifting, **allowing many more individual tools to emerge, via APIs access to a complex and rich backend**. *** ## Please explain how your proposal supports the Product Roadmap. This proposal provides direct-to-users tools that allow decision-making in Cardano to progress by fostering higher participation and transparency. This includes fostering and opening participation to key decisions related, but not limited to, key parameters, roadmaps, budgets, new or updates to the constitution, and more. *** ## If possible provide evidence of wider community endorsement for this proposal? Cardano GovTool has quickly become the hub for Cardano governance activity. **The Cardano community has been using and taking value from the applications that make up Cardano Govtool since before CIP-1694 was approved**. * **Over 30k unique users have used, tested, and provided feedback over the beta testing in SanchoNet GovTool**, which created a path to full governance. * **Hundreds of ideas and feedback have been submitted** via the open backlog stored in GitHub, showing participation in the evolution of the tool and ownership of it by the Cardano community. * The governance tools working group, which as of now has met more than 65 times, has become the focal point and trusted source of info for multiple builders in the governance space, which connect weekly to provide feedback and direction to Govtool and align on common standards. Since full governance came live with Plomin upgrade in September 2024, the **Cardano Govtool has had over 48k+ visits**, **over 76k+ page views in 170 countries** (with the highest usage in the USA, followed United Kingdom, Japan, Canada and Germany, and then Australia, Netherlands, Vietnam, Switzerland, Spain and many more). Check open analytics at . * It supported the **thousands of DReps registrations and delegations** (equivalent to millions of ADA) * **Thousands of votes** have been cast through GovTool’s interface * It hosts **hundreds of proposal** between the preview, preprod and mainnet instance * It has enabled ada holders to experience governance on testnet, with proposals, governance actions, DReps and delegations on [preview.gov.tools](http://preview.gov) and [pre-prod.gov.tools](http://pre-prod.gov) \ Importantly, the platform’s openness has enabled many community contributors to get involved: the governance working group reviews user feedback weekly, the GovTool GitHub repository and backlog are public, and improvements always originate from community direction. **Govtool’s open APIs have enabled multiple community builders** to provide value, such as: * [2025 Cardano Budget Reconciliation](https://2025budget.intersectmbo.org/) - Ekklesia - Adam Dean, Mad Orkestra * [Cardano Budget](https://cardanobudget.com/) - Tony | Thanh * [1694.io](http://1694.io/) - Darlington Wleh (Lido Nation) * [Tempo.vote](https://tempo.vote/) - Binh Mal * [Governance Space](https://governancespace.com/en-us) - Otavio Lima * [Cardano Budget Analytics](https://budget.cardano.africa/) - Dan Baruka * [1694.tools](https://1694-tools.vercel.app/) - Unpopular El Furthermore, Cardano GovTool’s fast support has enabled the Cardano community to have this Budget Proposal submission process available in record time (less than 10 working days), keeping it still open for integration via OpenAPIs.
The distributed model, which connects multiple applications in one cohesive experience, allows multiple builders and many individual participants to develop and evolve Govtool’s applications in parallel, as well as allowing anyone to take any part of GovTool as a reference implementation. This has encouraged wide positive support and participation so far. We believe the participation, usage, and value leveraged by other tools shows clear support to continue this effort, making it more and more structured, more and more efficient, and lean as we progress. *** ## Proposal Details ### Proposal Description This proposal aims to **push Cardano GovTool to be truly and organically maintained by individuals in the Cardano Community**, simplifying the bootstrapping model. The Cardano GovTool has been bootstrapped by community builders, with facilitation from Intersect, to get us to full Cardano governance and ensure open and transparent participation in it. Cardano GovTool was always meant to be **organically maintained by many community contributors**. The first steps towards that have been there from the start, by making it fully open source and having community test while building. Then all the steps of governance have been divided in different applications, to reduce dependencies and increase tool resilience, as well as giving more opportunities for Govtool backend to be used. Via an open grant process it has been maintained so far by 5 community builders, shaping the foundations, as well as growing and refining documentation to allow individual contributions.\ Furthermore, a working group has been active for over 1 year, collating community feedback and providing direction, becoming also the connection point of all the builders working on governance tools. These give now the foundation to push Cardano GovTool a step further, reducing the need for active regular development, making that useful but not mandatory, and expanding focus on increasing organic individual contribution. **Cardano Govtool is currently made of five independent pillars**: * **Voting** Pillar * **Delegation** Pillar * **Proposal Discussion** Pillar * **Outcomes** Pillar * **Budget Discussions** Pillar To support these pillars, there is an overall QA for end-to-end automated testing and DevOps to manage hosting and deployments of the 3 versions (preview GovTool, pre-prod Govtool and mainnet GovTool) **This proposal offers different levels of funding**. **All the options are community led and operated**. Every level will increase speed as well as feature improvements. These levels can be added on top of each other (level 1 can be actioned alone, to have level 2 you need level 1 as foundation, to have level 3 some or all elements of level 1 and 2 are needed). Additionally, to support decentralized development and streamline contribution workflows, we will partner with platforms like Andamio or similar to structure and distribute tasks transparently across the community. These are the 3 different levels and what they include:
Level 1 - Foundational Basic Maintenance This level secures the ongoing functionality of Cardano GovTool as public digital infrastructure, akin to projects like Node.js or Next.js, where a core team stewards development and ensures continuity. It covers the bare minimum required to keep Cardano GovTool operational and secure, enabling the community to build on a stable foundation. It includes: 1. **Hosting costs, infrastructure maintenance, CI-CD, security,** and minimum maintenance of this (*0.25 FTE*). It includes the following environments: 1. GovTool 1. Dev environment * Voting and Delegation pillars dev * Proposal and/Budget discussion pillars dev * Outcomes pillar dev 2. QA environment * Voting and Delegation pillars qa * Proposal and Budget discussion pillars qa * Outcomes pillar qa 3. Preview environment (preview\.gov.tools) * Voting and Delegation pillars preview * Proposal and Budget discussion pillars preview * Outcomes pillar preview * Preview instance of DB-sync 4. PreProd (pre-prod.gov.tools) * Voting and Delegation pillars preprod * Proposal and Budget discussion pillars preprod * Outcomes pillar preprod * PreProd instance of DB-sync 5. Mainnet (gov.tools) * Voting and Delegation pillars mainnet * Proposal and Budget discussion pillars mainnet * Outcomes pillar mainnet * Mainnet instance of DB-sync 2. CC Portal (constitution.gov.tools) 1. Mainnet 2. **Repo maintainer** (*1 FTE QA and 1 FTE full stack engineer, split between 4 people to reduce downtime*) 1. Code reviews 2. Ensure security 3. CI-CD 4. Ensure overall consistency and cohesiveness 5. Urgent bug fixes 6. Testing This level **does not compensate for feature development**, but ensures that the system stays available, stable, and secure for ongoing use and experimentation.
Level 2 - Incentivised participation Level 2 **introduces flexible incentives to reward meaningful community contributions**. \ This enables timely resolution of critical issues, improvements that go beyond the foundational scope and increase of individual contributors. \ Also it **provides incentives for other open source governance tools** that provide new and better ways to participate in Cardano Governance leveraging (and where possible expanding) Govtool code or Govtool APIs. This model acknowledges and supports the hybrid nature of open source: a core team drives stability and strategic direction, while a broader community contributes enhancements, both needing resources to thrive. Incentives include: * Direct compensation in ADA for accepted contributions * Preferential access to premium features (e.g., extended API usage) * Private sponsorship: external parties can expedite roadmap items by funding them directly
Level 3 - Pillar active development and maintenance This is the level to which currently Govtool has been maintained. \ \ This level **ensures active monthly maintenance of the pillars, this means guaranteed and quicker bug fixes and feature development**. This could be decided pillar by pillar depending on community direction. \ This level includes active end-to-end and automated testing. \ The active development and maintenance will be awarded as contracts directly by the community to contributors they deem as reliable. \ \ Pillars that can be added to this are: 1. Proposals Pillar (0.75 FTE) 2. Delegation Pillar (1 FTE) 3. Voting Pillar (1.25 FTE) 4. Outcomes Pillar (0.75 FTE) 5. Budget discussion Pillar (0.5 FTE) If this more comprehensive level is fully funded, the resources mentioned in the ‘Foundational level’ will not be needed (they might be needed if only some of the pillars have dedicated active development and maintenance, unless the builders there can spread the effort).
The governance body made of community members that will collate and document the direction for this open source project is currently the **Governance Tools working group**, but it can evolve based on the community wider direction. *** ## Please list any key dependencies (if any) for this proposal? The delivery and progress of Cardano GovTool are dependent on the overall support and participation from the community, making sure everyone has ownership of the tools to participate in their government. On the development side, the applications that make up Govtool are dependent on different libraries. These dependencies will be managed directly by the repo maintainers. *** ## How will this proposal be maintained and supported after initial development? Cardano Govtool has already passed the hardest part, its first implementation (creating standards and processes from scratch), and it’s now running with a decentralised open source model with multiple maintainers who keep the whole experience up and running as well as adding and improving existing features. *** ## Key Proposal Deliverable(s) and Definition of Done: What tangible milestones or outcomes are to be delivered and what will the community ultimately receive? Some key items already delivered in 2025 and in the roadmap include:
Already delivered in 2025 * Supporting discussion and submission of New Constitution and No Confidence governance actions * Supporting ada handle resolution * Support for DRep images * Support for CIP-129 DRep IDs * Support for metadata hosted on IPFS * Support for searching by DRep metadata * Support for PreProd network * Support for local specific denomination of figures * Support for mathematical styling within governance action metadata * Support for displaying constitutional committee ratification thresholds and not voted totals * Support for redirecting users to outcomes pillar from expired governance action links * Launch of outcomes pillar * Improved performance of DRep directory and Live voting
Planned * Expansion of the outcomes pillars to show transparently the full governance process, from early discussions, through voting, and to outcomes (either enacted decisions or rejected actions) * Improvement of the integration of the Constitutional Committee's votes and rationale * Expansion of DRep history (including voting history) to make it easier to leverage liquid democracy by selecting and updating delegation, as well as DRep favouring * Support to create group DReps, allowing a better distribution of power * Support to have group proposers discuss proposals and submit on-chain actions, lowering the barriers to submitting governance actions * Adding moderation to the proposal discussion pillar * Adding pre-governance polling to support in a transparent and decentralized manner the social processes that happen before governance actions are submitted (this includes, for example, the CC elections and the budget proposals) * Improve code documentation to expand the pool of individual contributors, helping reduce the costs of development and maintenance, and creating rewarding opportunities for everyone in the Cardano community, as well as simplifying the leveraging of open source code to create new governance applications that improve and refine further the experience * Expand further open APIs to allow many individual builders in Cardano to create tools to participate in governance * Expand support to make it easy to discuss and submit all types of governance actions * Integrate with CoSponsor for crowdfunding of the deposit needed to submit governance action on chain * Integrate with SyncAI tool to introduce more natural language interaction with Cardano governance and elevating possibilities for integration for diverse community tooling * More proposals and ideas collected from the community can be found: * In the open backlog * In the open discussions
*** ## Resourcing & Duration Estimates This Proposal aims to **fund support for Cardano GovTool for 12 months**. Depending on the level of funding chosen by the community the amount of resources allocated will vary. The resources indicated below will be provided by community builders. 1. Level 1 - Foundational Basic Maintenance 1. **Infrastructure maintenance** *0.25 FTE* 2. **Repo maintainer** *1 FTE QA* and *1 FTE full stack engineer* 2. Level 2 - Incentivised participation\ This will provide exponentially more **individual contributors** and so resources 3. Level 3 - Pillar active development and maintenance\ End-to-end and automated testings *1 FTE* (if this level is chosen, the 1 FTE mentioned in the foundational level can either be removed or added to this effort) 1. **Proposals Pillar** *0.75 FTE* 2. **Delegation Pillar** *1 FTE* 3. **Voting Pillar** *1.25 FTE* 4. **Outcomes Pillar** *0.75 FTE* 5. **Budget discussion Pillar** *0.5 FTE* The governance body made of community members that will collate and document the direction for this open source project is currently the Governance Tools Working. This group is made of volunteers which add to the count of resources. *** ## Previous experience The **Cardano GovTool has been the benchmark governance tool since the emergence of on-chain governance**, the **builders currently working on it have ****defined from scratch technical and user experience standards**** currently used by other governance tools**. The process is facilitated with the support of IntersectMBO, its committees, and working groups. The ongoing development and maintenance of GovTool requires a reliable and capable team. While current contributors, such as[ DQuadrant](https://dquadrant.com/),[ Byron Network](https://byron.network),[ WeDeliver](https://we-deliver.io),[ Lido Nation](https://www.lidonation.com/en), and[ Bloxico](https://bloxico.com/), have demonstrated long-standing commitment and technical expertise in the Cardano ecosystem, future funding rounds should remain open to other qualified teams as well. **Any team with the skills, transparency, and alignment with GovTool’s open-source mission is encouraged to participate in maintaining and advancing the project**. This ensures community choice, fosters innovation, and reduces long-term dependency on a fixed set of contributors. *** ## Costing ### Ada Amount **₳1,150,000** ### Amount in preferred currency ₳1,150,000 (**$920,000** - *USD to ADA Conversion Rate: 0.8*) for 12 months ### Cost breakdown The **funds requested cover 12 months of maintenance and improvement** for **5 applications** that make up GovTool. Because **GovTool remains community-owned**, funds will continue to be allocated via an open and transparent grant process, and also the iterations of the different applications that make up GovTool will be subject to pivoting steered directly by the Cardano Community feedback and needs. **This will be the first time these sets of tools, made as public good, will request funds to continue running**. So in this first instance the existing builders, which have invested effort and have the deepest expertise and knowledge to run them, will be requesting funds directly for the next 12 months. During this first 12 months more builders and individual contributors will be onboarded via incentivised bounties, giving more options for future maintainers. The commitment is to be efficient with funding, so **any budget remaining at the end of the 12 months will be returned to the Cardano Treasury**.
The budget cost breakdown is as follows:
Level 1 - Foundational Basic maintenance: $330,000 for 12 months Level 1 cost breakdown: 1. Hosting costs, infrastructure maintenance, CI-CD, security, and minimum maintenance of this (0.25 FTE) → **$90,000** 1. $5,000 per month for hosting costs (full cost breakdown available in the following [spreadsheet](https://docs.google.com/spreadsheets/d/1RwuE1JRRwNp_-M8h5KXpyOJyS0-SVXi9k5YxvGCx_Zo/edit?gid=256167646#gid=256167646)) including Dev, QA environments for the dev each of the pillars and Preview, PreProd and Mainnet production environments 2. $30,000 for 12 months infrastructure maintenance 2. Repo maintainer (1 FTE QA and 1 FTE full stack engineer, split between 4 people to reduce downtime) → **$240,000** 1. Code reviews 2. Ensure security 3. CI-CD 4. Ensure overall consistency and cohesiveness 5. Urgent bug fixes 6. Testing
Level 2 - Incentivised participation: $530,000 for 12 months (Level 1 + ₳250k at 0.8) Level 2 cost breakdown: * All in Level 1 * **₳150,000** to be allocated organically via direct contribution on the repos * **₳100,000** to be allocated to other open source governance tools that provide new and better ways to participate in Cardano Governance leveraging (and where possible expanding) Govtool code or Govtool APIs
Level 3 - Pillar active development and maintenance level: $920,000 for 12 months (Level 1 + Level 2 + $630k) Level 3 cost breakdown: 1. All in Level 1 2. All in Level 2 3. Options: 1. Active development and maintenance of all pillars:\ Level 1 and 2 ($290k) + Overall end-to-end testing ($120k) + All the pillars (Proposals $90k + Delegation $120k + Voting $150k + Outcomes $90k + Budget discussion $60k) → **$920,000** for 12 months (these removes the need of repo maintainers so the $240k cost is absorbed) 2. Only one or a combination of different pillars:\ (Any pillar combination is possible) 1. Level 1 and 2 ($530k) + Overall end-to-end testing ($120k) + Proposals pillar ($90k) → **$740,000** for 12 months\ \ *Proposals Pillar - rendered as part of Govtool experience (0.75FTE - $90,000)*\ *This covers the costs of software engineers, QA engineers, and DevOps support for the environments related to this application. They are responsible for maintaining the application, making sure it's always operational, they need to support and make easier external contribution as well as add new features defined in the community roadmap*\
2. Level 1 and 2 ($530k) + Overall end-to-end testing ($120k) + Delegation Pillar ($120k) → **$770,000** for 12 months\ \ *Delegation Pillar - rendered as part of Govtool experience (1 FTE - $120,000)*\ *This covers the costs of software engineers, QA engineers, and DevOps support for the environments related to this application. This application connects directly to the chain, requiring engineers with more niche skills. They are responsible for maintaining the application, making sure it's always operational, they need to support and make easier external contribution as well as add new features defined in the community roadmap*\
3. Level 1 and 2 ($530k) + Overall end-to-end testing ($120k) + Voting Pillar ($150k) → **$800,000** for 12 months\ \ *Voting Pillar - rendered as part of Govtool experience (1.25FTE - $150,000)*\ *This covers the costs of software engineers, QA engineers, and DevOps support for the environments related to this application. This application connects directly to the chain, requiring engineers with more niche skills. They are responsible for maintaining the application, making sure it's always operational, they need to support and make easier external contribution as well as add new features defined in the community roadmap*\
4. Level 1 and 2 ($530k)+ Overall end-to-end testing ($120k) + Outcomes Pillar ($90k) → **$740,000** for 12 months\ \ *Outcomes Pillar - rendered as part of Govtool experience (0.75 FTE - $90,000)*\ *This covers the costs of software engineers, QA engineers, and DevOps support for the environments related to this application. This application connects directly to the chain, requiring engineers with more niche skills. They are responsible for maintaining the application, making sure it's always operational, they need to support and make easier external contribution as well as add new features defined in the community roadmap*\
5. Level 1 and 2 ($530k)+ Overall end-to-end testing ($120k) + Budget discussion Pillar ($60k) → **$710,000** for 12 months\ \ *Budget discussion Pillar - rendered as part of Govtool experience (0.5 FTE - $60,000)*\ *This covers the costs of software engineers, QA engineers, and DevOps support for the environments related to this application. They are responsible for maintaining the application, making sure it's always operational, they need to support and make easier external contribution as well as add new features defined in the community roadmap*
*** ## Further information * [Cardano GovTool mainnet instance](https://gov.tools) * [Preview instance](https://preview.gov.tools) * [PreProd instance](https://pre-prod.gov.tools) * [Constitutional Committee Portal](https://constitution.gov.tools) * [Open Backlog](https://github.com/IntersectMBO/govtool/) * [Open GovTool repository (voting and delegation)](https://github.com/IntersectMBO/govtool/) * [Proposal Pillar repository](https://github.com/IntersectMBO/govtool-proposal-pillar) * [Outcomes Pillar repository](https://github.com/IntersectMBO/govtool-outcomes-pillar) * [GovTool Test Reports](https://intersectmbo.github.io/govtool-test-reports/) * [GovTool open app analytics](https://analytics.gov.tools/) * [Open Constitutional Committee Portal Repository](https://github.com/IntersectMBO/cc-portal) * [GovTool Docs](https://docs.gov.tools) * [GovTool Proposal Pillar API docs](https://be.pdf.gov.tools/api-docs/) * [GovTool Outcomes Pillar API docs](https://be.outcomes.gov.tools/) * [GovTool Voting and Delegation Pillar API docs](https://be.gov.tools/swagger-ui/#/) * [Cardano Govtool X Account](https://x.com/cardano_govtool) * [GovTool - a breakdown of the costs so far](https://docs.gov.tools/important-updates/govtool-maintenance-ending-soon/govtool-a-breakdown-of-the-costs-so-far) \
# Budget Proposal FAQs We will add here any question raised
The cost seem high for a fully open source tool available also for community to build upon Building an open source tools correctly does actually require more effort, especially if it's done in a decentralised way (and so is less cost-efficient than a privately owned close-source tool), because: a. Every new feature of bug fix needs to be correctly documented and verified via different levels of quality assurance testing. This requires more time, infra-resources, and people, then just developing and deploying.\ This is needed however to make sure the tool works (especially when so many other tools depend on it) and also to allow anyone to use the open source code (keeping detailed documentation updated). b. Also, Govtool is made of separate application, then rendered in one experience, covering the end-to-end governance process. This makes it easier for anyone to re-use and expand each application code, and make the experience more reliable by distributing and decentralising the development, so reducing risks of one builder failing and the whole Govtool going down. This however increases complexity in the development process. c. Even more, on top of decentralised development, also the direction is decentralised, coming directly from Cardano community, channeled via the Governance tools working group, this makes of course the process longer then a close-source, privately owned mono-repo tool, built by one team with a centralised decision making point.
Will the ~$1M ($920k) be a fixed cost over the years or will it taper down? The strategy described in the budget proposal is defined for these costs to gradually reduce over time by: a. Expanding the pool of contributor (especially individuals) via the better and better documentation, easier paths to contribute and re-use the code (using platform like Andamio which make it easy to get rewarded), all of this also supported by the level 2 incentives (₳250k) b. Govtool has supported Cardano community getting into full governance, enabling DRep registrations during bootstrapping phase, supporting Chang and Plomin Hard Fork ratification, and more generally providing ready solutions for other tools to interact with Cardano's Governance.\ These meant that for the past 20+ months the effort has been to add new features that were gradually coming to governance. Over the next 12 months, alongside adding improvements, refactoring will be conducted (and has already started) to make running these set of tools more efficient.
The element of "public good" and scrutiny on costs To safeguard Cardano’s democratic legitimacy, as Cardano community, we must maintain a reliable, neutral, open-source governance set of tools, fully community-owned, non-commercial, and free to access, built as public good. The element of public good is mentioned because Govtool is not owned by any company and it's not built for commercial reasons. It simply has been there to support Cardano's governance since before CIP1694 was approved to act as that minimum foundational option to always keep governance participation fair. So, this needs more scrutiny on costs, not less, because this is everyone's tool, proposed to be funded with Cardano's treasury. There is always more that can be done towards that. In the proposal there is detailed description of how the money will be allocated and why, down to the individual hosting cluster. Even more, historic costs for the past 20+ months have been documented [https://tinyurl.com/4xv3vb9x](https://t.co/OFa0QnCidd)
What's included in the $5000 per month for hosting Govtool is not just one tool, it is made of multiple applications, and the development of each of the follows common standards for reliability and quality assurance. Furthermore, Govtool provides access not only to Cardano governance on mainnet, but also on Preview and PreProd, giving more opportunities to ada holders, and dApps that rely on Govtool APIs, to test governance. The $5000 is estimated based on an avg of the current monthly costs which cover the enviroments listed below and more. GovTool: * Dev environment * Voting and Delegation pillars dev * Proposal and/Budget discussion pillars dev * Outcomes pillar dev * QA environment * Voting and Delegation pillars qa * Proposal and Budget discussion pillars qa * Outcomes pillar qa * Preview environment (preview\.gov.tools) * Voting and Delegation pillars preview * Proposal and Budget discussion pillars preview * Outcomes pillar preview * Preview instance of DB-sync * PreProd (pre-prod.gov.tools) * Voting and Delegation pillars preprod * Proposal and Budget discussion pillars preprod * Outcomes pillar preprod * PreProd instance of DB-sync * Mainnet (gov.tools) * Voting and Delegation pillars mainnet * Proposal and Budget discussion pillars mainnet * Outcomes pillar mainnet * Mainnet instance of DB-sync * CC Portal (constitution.gov.tools) * Mainnet Fully detailed cost breakdown is available at the following [link](https://docs.google.com/spreadsheets/d/1RwuE1JRRwNp_-M8h5KXpyOJyS0-SVXi9k5YxvGCx_Zo/edit?gid=256167646#gid=256167646).
FTE requirements for each pillars, and complexity of the application As mentioned above, Govtool is made of 5 separate complex application. It's development follows rigorous standards. Most of these application have created governance standards for tooling figuring out hard challenges from scratch (when on-chain governance was just a CIP). \ \ However, the most important element here is what is Govtool. As mentioned in this reply [https://tinyurl.com/2z437vpd](https://t.co/VInkne3Fq2) : Govtool is not just the user interface you see, over 90% of the effort is allocated in the open-source backend. This BackEnd is what powers a lot of the other governance tools (you can see some examples in this part of the proposal [https://tinyurl.com/58jdd3ne](https://t.co/Op7XhTJm7N))
Who is currently developing Cardano Govtool? Who is currently developing Cardano Govtool? Cardano Govtool is NOT built by Intersect developers. Intersect had (and still has) a facilitation role in the process, first of all via the Governance tools working group (which is an Intersect working group) and with dedicated staff supporting alignment between builders. Govtool is developed by Community Builders such as[@LidoNation](https://x.com/LidoNation) [@Juno\_stakepool](https://x.com/Juno_stakepool) [@bynetio](https://x.com/bynetio) [@We\_Deliver\_IT](https://x.com/We_Deliver_IT) (who also submitted the info action) and by individual contributors
Is Govtool just the front end experience we see on gov.tools? Govtool largest value is in its backend, available via open APIs Govtool is not just the user interface you see, over 90% of the effort is allocated in the open-source backend. This is made of 5 separate application (structured in this way to keep them reusable by other builders and reduce downtime), these are built following the best development standard (to ensure again uptime and reliability). And most importantly, this BackEnd is what powers a lot of the other governance tools (you can see some examples in this part of the proposal [https://tinyurl.com/58jdd3ne](https://t.co/Op7XhTJm7N))
why an open source tool is less cost-efficient than a close-source one? True decentralise open-source development is less cost-efficient than a centralised closed-source one To safeguard Cardano’s democratic legitimacy, as Cardano community, we must maintain a reliable, neutral, open-source governance set of tools, fully community-owned, non-commercial, and free to access, built as public good. Of course being this fully community-led and owned, and being built in the open in a decentralised way, makes it less cost-efficient, but it's necessary to meet the goal above. For reference, if Govtool was one application, closed-sourced, owned and built by one company, potentially it can be actively maintained by 4 engineers. At the moment, Govtool is one of the only (in some cases the only) open-source community owned governance tool for Cardano. Without it community participation in governance relies on the will of closed-sourced privately owned tools (most of which need Govtool APIs to work). \-- High standards for open-source development and access to multiple networks Contributing to the cost and complexity are the rigorous standards Govtool development follows. With dedicated development and quality assurance environments for each application, overall end-to-end automated testing and 3 production environments, one for each network (preview, pre-prod and mainnet), Govtool has the highest standards of development and engineering right now.\ This ensures also community access to these test neworks, allowing easier onboarding in Governance.
why does Govtool need funding if there are no protocol changes? * Govtool is not just dependent on Cardano's protocol changes (although when they happen you need to make sure to have resources to update and test all changes). It relies on different libraries so like any other tool, to remain operational requires a minimum effort this is described mostly in the level 1 of the proposal. * Also Govtool being community owned needs to support latest standards defined by Cardano community in CIPs. * Even more outside of the the new features or improvements requested by the community, there are adjustments needed as governance is in its early stages still and keeps evolving. So, in relation to effort and funding: * To keep the tools running at least the funding of level 1 described in the proposal is needed. * To support key updates to keep it relevant to the ever evolving Cardano governance, and so keep an foundational tool for participation, level 2 or level 3 are funding needed, depending on the speed of development the community expects. (If community feels Cardano's governance can remain easy to participate to, open and fair, only relying on privately owned tools, then no level of the proposal should be funded.)
what's in the roadmap You can see key planned (as well as delivered) initiatives here [https://tinyurl.com/4275j7w4](https://t.co/msEkcwvj5i). Important also to note that Govtool roadmap is directly defined by the Cardano community, so subject to change and evolution, so the best place to check what's coming next is the community backlog [https://tinyurl.com/dt84eyek](https://t.co/zbmLzWicEV) and the community discussion (recently started to make it easier to define direction) [https://tinyurl.com/34fs6nz3](https://t.co/KX5OroIeX1)
how will the incentives be distirbuted As mentioned in the proposal the incentives of level 2 (₳ 250k) will be allocated via platforms like Andamio following existing open-source bounty processes, where a task is defined and if completed, and then approved and merged, the reward can be paid (in this case it will be done on-chain).\ All this is directed by the community via the Governance tools working group
the hosting costs seem high High level there are costs of 0.25 FTE to manage that process (highly complex) and costs to run Dev, QA environments for each of the applications (5) and Preview, PreProd and Mainnet production environments (Keeping Govtool one of the few places where users can interact easily with governance also on preview and preprod). The full breakdown of the devOps costs can be found in the proposal with details down to the individual AWS service, you can check here [https://tinyurl.com/5c69eczn](https://t.co/Myu25O6jP6) and here [https://tinyurl.com/ms4yfxjk](https://t.co/sps9uY4B3J)
if this Budget info action is approved how will funds delivery be tracked The Cardano Govtool budget proposal, if approved and then funded via the treasury action, will be handled via the smart contract framework Intersect will use for the 39 treasury actions that will soon be submitted on-chain. The community incentives will be distributed transparently on-chain with platforms like Andamio. Even more, along side that on-chain transparency, Govtool development is open and transparent for everyone to check and contribute to: * Govtool open repos [https://docs.gov.tools/participate-in-development/governance-tools-repositories](https://t.co/wvOshTC1EW) * Govtool discussion [https://github.com/IntersectMBO/govtool/discussions](https://t.co/C1N9Dcu8QK) * Govtool open backlog [https://github.com/orgs/IntersectMBO/projects/34](https://t.co/YyGPSFjBgM)
How will the Level 2 incentives be allocated and what can the community expect from those? The incentives in Level 2 are divided in 2 parts. The first part is ₳150k. This has been proposed to incentivise more contribution to the Govtool development, especially from individuals, with the goal to make Govtool stronger and more resilient as an open-source project.\ How will it be allocated: As mentioned in the proposal, these incentives will be allocated via platforms like Andamio, following existing open-source bounty processes, where a task is defined and if completed, and then approved and merged, the reward can be paid (in this case it will be done on-chain). All this is directed by the community via the Governance tools working group. Prioritisation of task will still remain consistent to the overall process that uses the open backlog and open discussions. (this model will also open a process for sponsored features) The second part is ₳100k. This has been expanded during the open consultation period when the budget proposal got refined. Govtool has been acting as a foundational tool for governance participation for end users as well as key infrastructure for other tools.\ The proposal behind these incentives is to encourage the creation of other tools that can provide new and better ways to participate in governance using Govtool APIs or open-source code.\ How will it be allocated: These provides new ways for the end-user to interact with governance while brining new developers to the open-source project and improving the code itself.\ In this case there will be either defined requirements that have already been requested and prioritised by the community, in this case, like above, a task will be opened and if completed a reward will be paid, OR there could be a proposal set forward by a developer, which will then be prioritised (as above) and if completed will get rewarded. So in short, for both proposed incentives, there is the common step of collecting community input about the needs, if the need has support, it will be refined and become a task (more specifically a github issue) and then that task will be 'advertised' on platforms like Andamio (probably Andamio itself) where anyone can pick them up, and if successfully completed, get rewarded, tracking the all process transparently on-chain.
Why do we need Proposal discusson pillar and what's next for the budget proposal pillar? Whilst all pillars cover an important part of the governance process, some pillars have definitely more importance in the process than others, that is also why they have more or less resources budgeted for. Delegation, Voting and Outcomes definitely do cover the bulk of the participation on-chain and they are critical. Proposal discussion pillar (which might need actually a better name) is the pillar where anyone can draft a governance action in a fully guided process, discuss and get feedback (as the name suggests) and, more importantly, if the proposer is ready, it allows to submit the governance action directly to chain with checked metadata (so probably one of the safest and easiest option for anyone to submit their governance actions on-chain). This pillar, paired with co-proposing options to split the deposit cost, will further lower the barriers to participate in governance.\ Outside of these, also in the preview and preprod environments, we see heavy use of this pillar to test governance actions metadata as well as an easy way to get feedback on a governance action proposal before investing 100k deposit. The Budget proposal pillar has enabled the first budget process to progress this year. However, being the reflection of an interim process (also developed to support community needs in 9 business days) it will need refactoring. The goal there will be to facilitate and push forward the draft CIP to create a common standard for pre-governance polling, so that they are fully handled on-chain in a common way, allowing every tool to build an experience for the end-user to participate while submitting the votes to the same source of truth.
# Proposed roadmap Cardano Govtool direction and roadmap is community driven, both directly, via feedback and direct contribution, and more simply follows community’s priorities over time as governance evolves. You can see key planned (as well as delivered) initiatives here[ https://tinyurl.com/4275j7w4](https://t.co/msEkcwvj5i). Because Govtool’s roadmap is directly defined by the Cardano community, so subject to change and evolution, the best place to check what's coming next is the community backlog[ https://tinyurl.com/dt84eyek](https://t.co/zbmLzWicEV) and the community discussion (recently started to make it easier to define direction)[ ](https://t.co/KX5OroIeX1) . ## Initiatives that have clear community support Below is a list of initiatives that have shown to have community support from feedback collected in calls, on X and directly on github, so are currently being refine and prepared for implementation.
* Add DRep history on the DRep page. This will show what that DRep voted on, how and (if available) with what rationale. Furthermore it will show the delegations moving in and out. All this will provide better context to the delegator, also opening new options to sort and filter DReps. * Add voting history on Governance Actions (both those up for voting and those that have been ratified or rejected). This will allow DReps and ADA holders to see directly on the Governance Action page, alongside all the context coming from the metadata, the details related to voting, making it easier also to see if their DRep voted as they expected, thus enabling liquid democracy. * Add support to easily create group DReps. This will enable smaller DReps to easily come together and build strong coalitions so further distributing voting power. Alongside this, add support to allow group DReps to use Govtool. * Add support for group proposers. Creating a Governance Action with multiple authors is a very hard challenge, with many opportunities for mistakes. Making it easier for multiple authors to submit a Governance Action will foster the creation of more governance actions, provide more clarity on-chain about where the proposal comes from, it will allow to divide the cost of the Governance Action deposit, hence lowering the barrier for participation to the global community. * Add general support for multisig wallets. This will expand the pool of participants that will benefit from a simpler experience. The features is currently proposed to be implemented with an integration with ‘Mesh’. * Add Constitutional Committee vote details on Governance Actions (both those up for voting and those that have been ratified or rejected). This will make it easier to see which constitutional committee voted on a specific Governance Action and why they voted in that way, all on the same page. * Add an easier way for delegators to identify DReps by helping finding DReps that have voting history aligned with delegators voting principles. * Add option for anyone to open surveys and polls to DReps and SPOs. This will make it easier to have pre-onchain governance sentiment checks. The effort here is related to the creation of a standard for off-chain polling that all tools can use. * Ability to submit more than one vote in one transaction. This will make it easier for DReps to vote during times when many governance actions are on-chain * Further expand open APIs coverage to include access to submission for all types of governance actions. This will make it easier for other builders to include this critical feature faster, drammatically lowering the barriers to submit a governance action. * Generally expand options for individual contribution to the open source code. Specifically integrate the GitHub backlog with the Andamio platform to allow anyone to get onboarded to the repos and be rewarded for meaningful contribution to key identified issues * Optimise the hosting and deployment infrastructure to reduce cost and make general maintainance more efficient


# Govtool Builder monthly responsibilities ## For Builders handling one of the pillars As one of the Govtool maintainers, the Builder shall carry out all the duties that are commonly connected to this role in an open source project, for projects supported by Intersect this will evolve and be refined by the Intersect Open Source Committee, they include but are not limited to: * Reviewing and merging pull requests * Keeping relevant documentation updated * Participating in governance tools WG sessions * Triaging github issues raised related to their repos and pillars * Support **their assigned Govtool Pillar** (bugs - both tech and design, adjustments - both tech and design, preview, preprod and mainnet updates) * Review and validation of internal and user submitted bugs * Fixing bugs based on the Customers triage process (Bugs related to features out for beta testing will be categorized as: Bugs from previous SoW, Bugs related to new issues) * Connect with other maintainers of Govtool to maintain, support, and evolve Govtool as a whole, including the Govtool wrapper * Make their repos accessible by also supporting individual contributors or other organizations in contributing to any stage of software development * Contribute, support and foster distribution of duties and decentralization of operations and development of Govtool * Update Govtool pillars they are responsible for to accommodate changes coming from external components that include, but aren't limited to: * Other pillars * DBSync * Node * Standards as defined in CIPs * Make sure Govtool pillars they are responsible for fully work on desktop, tablet and mobile (web-responsive) * Make sure Govtool pillars they are responsible for are fully working for and on mainnet * Support for other test networks before mainnet (including anything related to support multinetwork) * Make sure their Govtool pillar is ready to support initiatives related to sponsoring Cardano 1694 adoption. These include, but aren't limited to: * Events * Campaigns * Anything that might be useful to increase adoption * Make sure pillars are functional and can be communicated and openly used at any public event *** ### Acceptance Criteria: * Relevant documentation in the pillar respective repo is up to date * Team regularly triages bugs and is participating in the bug triage sessions * Relevant and agreed bugs and improvements are fixed and deployed * Connection with other maintainers is kept on a regular basis * Repo documentation for proposal discussion is improved and contributed to sufficiently * Code in the pillar is up to date with the latest changes in the external components that include but aren't limited to: * Other pillars * DBSync * Node * Standards as defined in CIPs * GovTool is fully working and operational without P0 and P1 issues * Key representatives of the supplier’s team (maintainer) join and actively participate in the Intersect community open working group (as of now, governance tools working group) and work to improve its processes ## For builder handling end-to-end testing The Builder shall provide and carry out the following: * Develop and improve DApp level tests for GovTool on Preview, PreProd and Mainnet ### Acceptance Criteria * Develop and execute DApp level tests for GovTool * Potential additional services or tests are identified and documented * Tests should include, but aren't limited to, the following: * Integration testing * System (end to end) testing * Performance testing * Load testing * Stress testing * Scalability testing * Security testing * Penetration testing * Regression testing * Smoke testing * Sanity testing * API testing * Testing should have several forms * Automation testing * Manual testing * Continuous Testing: Integrating testing into the CI/CD pipeline # GovTool - a breakdown of the costs so far To provide transparency and context, here is a breakdown of GovTool-related costs to date, aligned with its evolving role in Cardano governance. {% hint style="info" %} The budget broken down below was distributed to community builders: **ByronNetwork, DQuadrant, WeDeliver, Bloxico, Lidonation** {% endhint %} ## Early Bootstrapping: Pre-CIP-1694 Approval Before CIP-1694 was approved, GovTool was bootstrapped to help users visualize and test the proposed governance process. This phase was sponsored by IOG and delivered in collaboration with two builder teams. * Initial development ( Core features and initial UX): \~$50K * End-to-end automated testing (GovTool + CIP-1694 use cases): \~$20K {% hint style="info" %} Total: \~$70K {% endhint %} *** ## Post-CIP-1694: Foundation and Expansion (Jan–Jun 2024) Following the approval of CIP-1694 and Intersect’s official role, development was directed by the Governance Tools Working Group, utilizing a distributed builder model and community-reviewed grants.
GovTool v1 launch + continuous SanchoNet testing: €248.9K (~$282K) Evolution of Govtool v0 made before last 1694 workshop to Govtool v1 to fully support live voting, DRep registration, retirement, search and delegation, while keeping SanchoNet Govtool live on a production environment for continuous testing, feedback and improvements Beginning of January 2024 to end June 2024 €248.9k = \~$282k
Constitutional Committee Portal: ₳128K (~$64K @0.5) To cover the whole governance process, envisioning needs ahead of betting to bootstrapping phase and increasing chances of participation and so success, a grant was opened and awarded via community reviews for a Constitutional Committee Portal to host a simple to read version of the constitution, a record of the Constitutional committee members, an easy way for them to create vote rationales and make them visible and available to ada holders. ₳128k = \~$64k (at 0.5)
Proposal Discussion Pillar: ₳135K (~$67.5K @0.5) To cover the needs described in CIP-1694 about off-chain socialisation and discussion before a governance action is submitted on-chain, and to make it easy for people to submit a governance action with guided process to structure metadata too, a grant to add a Proposal discussion section was opened and awarded via community reviews ₳135k = \~$67.5k
Expanded testing: €84K (~$95K) With refinement and feature growth, to ensure correctness of implementation and reliability the amount and type of automated tests for all the features connected to on chain cardano governance did evolve and expand Beginning of January 2024 to end June 2024 84k euros = \~$95k
DevOps: CI/CD and hosting strategy: €8.5K (~$9.6K) With addition of new part of the governance process such as expanded delegation features, proposal discussion and constitutional committee support, as well as the increase of network supported also the complexity of the CI-CD and hosting grew needed to define an overall 8.5k euros = \~$9.6k
DevOps strategy implementation and management: $52K Following the initial DevOps strategy, hands on implementation of that strategy and management was needed $52k
{% hint style="info" %} Total: \~$570K for the initial 6 Months {% endhint %} *** ## Maintenance & Maturation (Jul–Dec 2024) As the tooling matured, emphasis shifted toward maintenance and refinement, ensuring stability during key phases like bootstrapping and the first governance actions.
Voting & Delegation pillar 6 months maintenance: €136.8K (~$155K) To support full time the voting and delegation pillars, core to governance participation to reach the first community voted hard-fork and then full governance, a maintenance contract was awarded to cover from June 2024 to December 2024 Beginning of June 2024 to end December 2024 €136.8 = \~$155k
Ongoing testing 6 months support: €37K (~$42K) Progressing from testnet to bootstrapping phase and then to full governance, while keeping up with recurrent node updates needed robust testing to support all the applications that make Govtool, for this a maintenance contract was awarded to cover from June 2024 to December 2024 Beginning of June 2024 to end December 2024 €37k = \~$42k
Proposal Discussion pillar 6 months maintenance: €42K (~$47K) To allow community to continue testing and participating in governance by making it easy to discuss and submit a governance action, on all networks, a maintenance contract was awarded to support the proposal discussion pillar and cover from June 2024 to December 2024 Beginning of June 2024 to end December 2024 €42k = \~$47k
Outcomes pillar grant: ₳76K (~$38K @0.5) To close the governance process loop, and allow ada holders to see the outcomes of the governance actions, a grant was opened and awarded for the Outcomes pillar ₳76k = \~$38k (at 0.5)
DevOps + hosting for 6 months for all networks (SanchoNet, Preview, Preprod, Mainnet: €32K (~$36K) To continue properly hosting and deploying all 5 pillars (applications) of Govtool on SanchoNet, Preview and Mainnet a devOps maintenance contract was awarded to cover from June 2024 to December 2024 Beginning of June 2024 to end December 2024 €32k = \~$36k
{% hint style="info" %} Total: \~$318K for the following 6 months {% endhint %} *** ## Sustained Maintenance (Jan–Jun 2025) To support the roadmap ratification and Cardano’s first budget process, maintenance contracts were extended into 2025 at reduced cost: * **Voting & Delegation pillars 6 months maintenance**: €95K (\~$107K) * **Constitutional Committee Portal 6 months maintenance**: €48K (\~$54K) * **Proposal Discussion pillar 6 months maintenance**: €52K (\~$59K) * **Outcomes pillar 2 months maintenance**: \~$4K * **End-to-end testing 6 months maintenance**: €28K (\~$31.5K) {% hint style="info" %} Total: \~$255.5K for these last 6 months {% endhint %} *** ## Summary Initial costs were high due to the innovative nature of GovTool — a platform designed from scratch to serve a governance model that had never been implemented before. However, recent figures are a more accurate reflection of ongoing costs to maintain and evolve a live, multi-network governance system.
# Core Governance Tools Governance tooling is owned and maintained by the community. With community approval, Intersect, through its committees and working groups, plays an important role in hosting and maintaining these governance tools. Through active community involvement, the aim is to create the initial Governance foundation layer together with different builders in the community. These governance tools support the whole process, both off-chain and on-chain, and as a whole they support the implementation of the governance described in CIP-1694 and its adoption. The community is able to further contribute to these tools by maintaining and improving existing features and pillars, creating new features or completely new areas either by themselves or supported by awards and grants facilitated by Intersect. With the freedom to test and refine Cardano’s next era of governance principles under one central apparatus, GovTool helps the Cardano community forge a future governance framework that represents the community’s best democratic interests. ## What? * The core governance tools are a set of two minimum viable tools for ada holders to interact with Cardano's on-chain governance. ## Why? * CIP1694 adds the ability for governance to Cardano, but to make it easier than CLI to use * to ensure legitimacy we need to make it easy to use for ada holders ## How? * Intersect and community builders * Governed by the governance tools working group ### Where? # Access the Core Governance Tools {% hint style="warning" %} These are the official core governance tools sites - be wary of any other site claiming legitimacy. {% endhint %} ## Cardano GovTool Instances ### Mainnet * [**gov.tools**](https://gov.tools/) ### Preview Testnet * [**preview.gov.tools**](https://preview.gov.tools/) ## Constitutional Portal Instances ### Mainnet * [**constitution.gov.tools**](https://constitution.gov.tools/) # System status This page shows the system status and known issues ## Check Govtool system status * [Mainnet](https://status.gov.tools/status/gov-tools) * [Preview](https://status.gov.tools/status/preview-gov-tools) Check Constitutional Committee portal system status * [Mainnet](https://status.gov.tools/status/cc-portal) * [SanchoNet](https://status.gov.tools/status/sancho-cc-portal) ## 🚨 Known Issues ### Cardano GovTool For an up-to-date list of all known issues and bugs please refer to [Github GovTool/Issues](https://github.com/IntersectMBO/govtool/issues). * *Proposing all types of governance action for discussion via proposal forum* ### Constitutional Committee Portal For an up-to-date list of all known issues and bugs please refer to [Github CC-Portal/Issues](https://github.com/IntersectMBO/cc-portal/issues). * *none!* # What is Cardano GovTool? The Cardano Govtool is a community tool that supports the key steps of Cardano's Governance process as described in [CIP-1694](https://github.com/cardano-foundation/CIPs/blob/master/CIP-1694/README.md). Govtool is part of the core governance tools. Intersect has facilitated the bootstrapping of GovTool and supported the process to fully open source it, allowing community ownership for improvement and maintenance. The Cardano Govtool, together with the other core tools such as the Constitutional Committee Portal, is currently managed by the Intersect [Governance tools WG](https://intersect.gitbook.io/intersect-committees-groups/groups-overview/working-groups/governance-tools-working-group), the four existing pillars that make Govtool (Proposal Discussion, Delegation, Outcomes and Voting) are developed and maintained by the WeDeliver Team, the Byron team, the Lido Nation team and tested by the DQuadrand team. GovTool is an application that enables users to participate in many ways in the governance of the Cardano blockchain. ### GovTool enables ada holders to: * View [Governance Actions](/cardano-govtool/using-govtool/governance-actions) with or without connecting a wallet. * Register to vote ([Direct Voter](/cardano-govtool/using-govtool/direct-voting)) without becoming a DRep. * [Delegate Voting Power](/cardano-govtool/using-govtool/delegating/delegate-to-a-drep) to a DRep * Register to become a Delegated Representative ([**DRep**](/cardano-govtool/using-govtool/dreps/register-as-a-drep)), allowing others to delegate their voting power to the DRep. * [Vote on Governance Actions](/cardano-govtool/using-govtool/governance-actions/vote-on-governance-actions) - available to users that are registered to vote as DReps or Direct Voters. * See outcomes of [Governanace Action](/cardano-govtool/using-govtool/governance-actions) votes. * [Propose](/cardano-govtool/using-govtool/governance-actions/propose-a-governance-action) a Governance Action. # What is the Constitutional Committee Portal? The Constitutional Committee Portal is a place for you as a member of the Cardano community to read the Constitution, and find out about the Constitutional Committee, including who they are, how their members have voted, and to read their rationales. # Community Governance Tools ### DRep Campaign Platform - [1694.io/dreps](https://www.1694.io/en/dreps) The DRep Campaign Platform is a community built platform for facilitating connecting, collaborating, and campaigning between DReps and the Cardano community. DReps amplify your voice and drive impactful decisions. #### Access * Mainnet instance: * Preview instance: * SanchoNet instance: [https://sancho.1694.io/en/dreps](https://preview.1694.io/en/dreps) * Github: *** ### Reach Your People - [ryp.io](https://www.ryp.io/) RYP is a web-based service that connects NFT projects, Decentralized Autonomous Organizations (DAOs), Stake pool operators, governance staff (DReps) and other decentralized organizations with their members on the public blockchain Cardano. It allows organizations to send notifications to their members, regardless of the communication channels they use. The service is designed to privacy-preserving for users that want to be in the know without exposing their wallet or social media information directly with projects. #### Access * Site: * Github: *** ### [Tempo.vote](https://tempo.vote/about) Tempo offers ADA holders insights into DRep voting behaviors through their profiles. DRep can engage with delegators, fostering open dialogue before voting on the Cardano blockchain. #### Access * Mainnet instance: * Preview instance: * SanchoNet instance: *** * [Cardano Budget](https://cardanobudget.com/) - Tony | Thanh * [1694.io](http://1694.io/) - Darlington Wleh (Lido Nation) * [Governance Space](https://governancespace.com/en-us) - Otavio Lima * [Cardano Budget Analytics](https://budget.cardano.africa/) - Dan Baruka * [1694.tools](https://1694-tools.vercel.app/) - Unpopular El # Cardano Govtool Consortium Cardano Govtool is a set of open source tools created for the public good to ensure ADA holders will always have a non-commercialised, non-privatized way to participate freely and transparently in Cardano's governance. To allow the community members and builders who actively participate in the maintenance and development of these tools to act as one a consortium was created. Current member of the Cardano Govtool Consortium are: * Govtool current maintainers * LidoNation - [lidonation.com](https://www.lidonation.com/en) - [@LidoNation](https://x.com/LidoNation) * ByronNetwork - [bynet.io](https://www.bynet.io/) - [@bynetio](https://x.com/bynetio) * DQuadrant - [dquadrant.com](https://dquadrant.com/) - [@Juno\_stakepool](https://x.com/Juno_stakepool) * WeDeliver - [we-deliver.io](https://we-deliver.io/) - [@We\_Deliver\_IT](https://x.com/We_Deliver_IT) * Bloxico - [bloxico.com](https://bloxico.com/) - [@Bloxic0](https://x.com/Bloxic0) * Builders who leverage Govtool open APIs for their tool * [Cardano Budget](https://cardanobudget.com/) - Tony | Thanh * [1694.io](http://1694.io/) - Darlington Wleh * [Tempo.vote](https://tempo.vote/) - Binh Mal * [Governance Space](https://governancespace.com/en-us) - Otavio Lima * [Cardano Budget Analytics](https://budget.cardano.africa/) - Dan Baruka * [1694.tools](https://1694-tools.vercel.app/) - Unpopular El * Regular Members of the Governance Tools Working Group (the body that collates community direction) * Phil Lewis - [@phillewisit](https://x.com/phillewisit) * Jonah Koch - [@jonahkoch](https://x.com/jonahkoch) * Bosko Majdanac - [@BoskoMajdanac](https://x.com/BoskoMajdanac) * Pedro Lucas # Using Govtool GovTool can be used in the following ways: * View [Governance Actions](/cardano-govtool/using-govtool/governance-actions) with or without connecting a wallet * Vote on Governance Actions directly by becoming a [Direct Voter](/cardano-govtool/using-govtool/direct-voting). * Become a [**DRep**](/cardano-govtool/faqs/what-is-a-drep) **(**Delegated Representative). DReps are able to vote on Governance Actions, they can also accept delegated Voting Power from others. A DRep's total Voting Power is the sum of their wallet balance and the Voting Power from others delegating to the DRep. * Delegate [Voting Power](/cardano-govtool/faqs/what-is-voting-power) to a DRep. This is a way for users that don't want to vote themselves to choose a representative to vote on their behalf * See results of Voting on Governance Actions. This is available to any public user. * Propose a Governance Action * Participate in discussions on proposed Governance Actions. # Getting started This is an overview of the process for installing and using the GovTool. Each step will be explained in detail in further pages. ### To run GovTool, you need: * A Chromium Browser. * A Windows or Apple computer. * A compatible wallet. Please see the [compatible wallet list](/cardano-govtool/using-govtool/getting-started/compatible-wallets). ### Step-by-step instructions 1. Download a [compatible wallet](https://docs.sanchogov.tools/how-to-use-the-govtool/getting-started/get-a-compatible-wallet) 2. Create an account in your wallet. Please refer to the wallet's documentation to create an account. 3. If you want to use the Preview network: 1. Set your wallet's network to "Preview". This will be different for each wallet. Refer to the documentation of your wallet. 2. Get some test ADA from the Cardano testnet [faucet](https://docs.cardano.org/cardano-testnets/tools/faucet/). 3. Navigate to: 4. To use the MainNet version of GovTool, go to: 5. [Connect your wallet](/cardano-govtool/using-govtool/getting-started/connect-your-wallet-to-govtool) to GovTool by using the "Connect" buttons on the interface. 6. You now have several options: 1. [Browse on-chain Governance Actions](/cardano-govtool/using-govtool/governance-actions/vote-on-governance-actions). 2. [Vote on an action by becoming a dRep](/cardano-govtool/using-govtool/dreps/register-as-a-drep). 3. '[Abstain](/cardano-govtool/using-govtool/governance-actions/vote-on-governance-actions)' on every Governance Action by default. 4. [Vote "No"](/cardano-govtool/using-govtool/governance-actions/vote-on-governance-actions) on every action by default. 5. [Become a dRep](/cardano-govtool/using-govtool/dreps/register-as-a-drep) yourself, and gain voting rights. 6. Become a [Direct Voter](/cardano-govtool/using-govtool/direct-voting) and vote on Governance Actions with your own Voting Power 7. Propose your own [Governance Action](/cardano-govtool/using-govtool/governance-actions/propose-a-governance-action) 1. Note: The [Bootstrapping](/cardano-govtool/faqs/bootstrapping-phase) phase will support only the creation of 'Info' Actions. 2. GovTool on [SanchoNet](https://sanchogov.tools) currently supports 'Info' and 'Treasury' actions. Using SanchoNet will require you to change the network your wallet is connected to to "SanchoNet". # Compatible Wallets {% hint style="warning" %} GovTool requires Cardano wallets to have upgraded to CIP-95 to be able to connect and share governance data, thus some existing Cardano wallets might not work. {% endhint %} ### Mainnet Compatible Wallets (`gov.tools`) Wallets which are working with GovTool on Mainnet.
WalletDownload linkStatus
Eternlvisit siteOnline
Lacevisit siteOnline
NuFivisit siteOnline
Vesprvisit siteOnline
Typhonvisit siteOnline
Yoroivisit siteOnline
Ledger (hardware)visit siteCompatible *(see note)
Trezor (hardware)visit siteCompatible **(see note)
Keystone (hardware)visit siteCompatible
FlintN/AWill not progress (see announcement)
NamiN/AWill not progress - Nami users are encouraged to upgrade to Lace for governance functionality - see blog.
\*Ledger devices support all governance activities via GovTool, except submission of governance actions. \*\*Trezor devices are limited with their governance functionality, only supporting DRep vote delegation via GovTool. ### Preview Network Compatible Wallets (`preview.gov.tools`) Wallets which are working with GovTool on Preview testnet. | Wallet | Download link | Status | | ---------- | ---------------------------------------------------------------------------------------------- | --------------------------------------------------------------- | | **Eternl** | [visit site](https://chromewebstore.google.com/detail/eternl/kmhcihpebfmpgmihbkipmjlmmioameka) | Online | | **Lace** | [visit site](https://chromewebstore.google.com/detail/lace/gafhhkghbfjjkeiendhlofajokpaflmk) | Online | | **Vespr** | [visit site](https://vespr.xyz/) | Online | ### SanchoNet Compatible Wallets (`sanchogov.tools`) Wallets which are working with GovTool on SanchoNet. | Wallet | Download link | Status | | ---------------------------- | -------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------- | | **Eternl** | [visit site](https://chromewebstore.google.com/detail/eternl/kmhcihpebfmpgmihbkipmjlmmioameka) | Online | | **Nufi** *SanchoNet Version* | [download here](https://assets.nu.fi/extension/sanchonet/nufi-cwe-sanchonet-latest.zip) | Online | | **Yoroi (Nightly)** | [visit site](https://chrome.google.com/webstore/detail/yoroi-nightly/poonlenmfdfbjfeeballhiibknlknepo/related) | Online | ### Wallets with in-wallet governance functionality Some wallets have chosen to add the governance functionality in-wallet. This means that some governance flows are supported without leaving the connecting to GovTool or leaving the wallet. | Wallet | Download link | Description | | -------------------- | ----------------------------------------------------------------------------------------------------- | --------------------------------------------------------- | | **Eternl** | [visit site](https://chromewebstore.google.com/detail/eternl/kmhcihpebfmpgmihbkipmjlmmioameka) | Supports DRep delegation in wallet. | | **Typhon** | [visit site](https://chromewebstore.google.com/detail/typhon-wallet/kfdniefadaanbjodldohaedphafoffoh) | Supports DRep delegation in wallet, with a DRep explorer. | | **Yoroi** | [visit site](https://chromewebstore.google.com/detail/yoroi/ffnbelfdoeiohenkjibnmadjiehjhajb) | Supports DRep delegation in wallet. | | Daedalus (full node) | [visit site](https://daedaluswallet.io/) | Supports DRep delegation in wallet. | # Connect your wallet to GovTool Open your Chrome browser, and navigate to
To start using the SanchoNet Govtool functions, you need to Connect your wallet. Simply click the "Connect Wallet" button at the top of the page. You will see a pop-up showing you the wallets available on your browser, select your chosen wallet to connect.
You will be asked for permission to connect with GovTool. To proceed, agree to this. Allow access and confirm the transaction, and you will be taken to the dashboard.
# The GovTool Dashboard The actions you can perform from the dashboard once you connected your wallet The dashboard allows you to access all the functions of GovTool. You can: 1. **Delegate your Voting Power to a DRep, who will vote as your proxy** 2. **Vote on your own without delegating to a DRep (ada deposit required: Refunded upon completion of voting or expiry of voting period)** 3. **Propose a Governance Action (ada deposit required: Refunded upon completion of voting or expiry of voting period)** 4. **Become a DRep and enable delegation to yourself, which increases your Voting Power** 5. **View and Vote on Governance Actions**
# Direct Voting Direct Voting is where any ADA holder can vote on any Governance Action. To be eligible to vote, you must register: 1. You will need ADA in a compatible wallet ([see list of compatible wallets](/cardano-govtool/using-govtool/getting-started/compatible-wallets)) 2. Your ADA balance in your wallet must be large enough to cover a 500 ADA deposit (which is refundable) plus any transaction fees - (currently less than 0.2 ADA) 3. Click on "Register" in the "Become a Direct Voter" panel on the Dashboard to get started\ ![](/files/Wxq4t0qWHQanO49BBu1U) 4. Follow the prompts to register. You will simply be asked to sign a transaction. 5. Wait a few minutes. 6. When the transaction is completed on the chain, the dashboard will change to show that you are registered to vote. 7. You can now vote on any [Governance Action](/cardano-govtool/using-govtool/governance-actions) # DReps DReps (Delegated Representatives) are ADA holders who registered On-Chain to allow other members of the community to delegate their voting power to them, so that they can vote on their behalf. They are are like 'parlimentary representatives' in the Governance system. Any ADA holder can become a DRep. They simply need to register on GovTool (or other platform). DReps are defined by [CIP-1694](https://www.1694.io/). They can: * Submit Governance Actions * Review and submit votes on active Governance Actions * Accept delegated Voting Power from any ADA holder When a DRep votes on a Governance Action, they vote with all the [Voting Power](/cardano-govtool/faqs/what-is-voting-power) that is delegated to them. # Register as a DRep How to register as a DRep 1. **Dashboard**\ From the dashboard, click "Register" in the "Become a DRep" panel:
2. **Roles and Responsibilites**\ Explains what a DRep does, and tells you about the refundable deposit.
3. **DRep Info**\ The DRep name is required, and there are three other fields that are optional: Email, Bio, and Link(s). You can add up to 8 links. This information will be displayed you your DRep page, and publicly available to all users of GovTool
4. **Data storage confirmation**\ DRep data is not stored on-chain. Every DRep must responsibly store their information off-chain and pass that link back to GovTool (on the following screen). You must check the box and agree to this to proceed with registration.
5. **Storing your information**\ There are three steps to storing your information: 1. Download the file to your computer. This file contains the DRep registration info that you entered in the registration form. 2. Save the file in a location that will provide you with a publicly-accessible URL. 3. Copy the URL from the location above and paste it into the URL field. 6. **Example using GitHub** [**See example using IPFS**](#ipfs)\ \ This example uses a new public repo for simplicity. 1. Upload the file you downloaded in the step above to GitHub 2. Commit the changes to the repository with the green button at the bottom right
7. **In GitHub, find the file you uploaded, click on it's name.**
8. **In Code view, click on the "Raw" button**\ This will take you to the 'Raw' view where you can copy the URL for the code
9. **In the Raw view, click on the URL in the top bar and copy it**
10. **Return to GovTool and paste in the URL** \ Then click "Submit"
11. **Sign the transaction in your wallet**\
12. **Your transaction will be submitted to the blockchain**
13. **Now you are registered as a DRep**
#### Store data using IPFS One of the simplest ways to store data using IPFS is by using the IPFS desktop app. You can download it here:

IPFS Download page

Choose your platform and download and install the desktop app on your computer. Upload the .jsonld file you from GovTool to IPFS by using the "Import > File" option on the top right of the screen
Once the file is uploaded, you need to set it's 'pinning'. Select the file in the list, click on the three dots at the far right of the screen, and choose "Set Pinning"
Click the "Local Node" checkbox and then the "Apply" button
You will now see the Files list again. Click the three dots again, and choose "Share Link"
Click "Copy" to copy the link
Paste it back into GovTool and click "Submit"
Sign the transaction with your wallet:
Your transaction will be checked and submitted:
You can return to the dashboard, and when the transaction is submitted, you will see your DRep registration there.
You are now registered and can vote as a DRep and also accept delegated voting power from others. # Retire as a DRep If a DRep no longer wants to participate in Governance, they can opt to retire. Retiring means that a DRep gives up voting rights. Voting Power that is delegated to the DRep will remain in place, i.e. will still be 'delegated' to the DRep's ID. ADA Holders that have delegated to be able to see that a DRep is retired in the DRep directory. They will be able to re-delegate their Voting Power to another DRep. Retired DReps can still participate in Governance by proposing Governance Actions, by delegating their personal Voting Power to another DRep, or by coming out of retirement, and assuming their previous role as a DRep. If a DRep comes out of retirement, their DRep ID will be the same as it was before retirement, and their Voting Power will consist of their own ADA balance and what delegated power that is associated 
to your DRep ID. # DRep error conditions ## There are four possible errors with DRep data These errors arise when GovTool cannot find or cannot verify the data entered and stored by the DRep, at the time of the most recent registration or data change ### Data Missing #### The data that was originally used when this DRep was created has not been found. GovTool uses external sources for DRep data, and these sources are maintianed by the DReps themselves. This error means that GovTool cannot locate the data on the URL specified when the DRep was originally registered. ### Data Not Verifiable #### The data that was originally used when this DRep was created has changed. GovTool uses external sources for DRep data, and these sources are maintianed by the DReps themselves. This error means that the data stored by the DRep does not match the data supplied by the DRep when they originally registered ### Data Formatted Incorrectly #### The data that was originally used when this DRep was created has been formatted incorrectly. GovTool uses external sources for DRep data, and these sources are maintianed by the DReps themselves. This error means that the data stored by the DRep does not match the format defined by the DRep spec. ### Data Not Verifiable #### The data that was originally used when this DRep was created has changed, and is not in the correct format. GovTool uses external sources for DRep data, and these sources are maintianed by the DReps themselves. This error means that the data stored by the DRep does not match the data supplied by the DRep when they originally registered, and that the data is not in the correct format as specified by the DRep spec. # Cardano Budget Proposals This page provides a simple overview about the Budget Proposals section of Govtool ## Overview The Budget Proposals section is a space for the Cardano community to submit proposals they want to be included in the next Cardano budget. By submitting them here proposers will be able to get comments and feedback from ada holders and DReps. ## How to use this section In the Budget Proposal section, you can: * Review and comment on existing proposals * Submit, edit, or delete your own proposals * If you are a DRep you can provide your sentiment about that proposal via a simple poll * If you are a member of the Intersect Committees you can provide recognisable feedback ### Quick video guide {% embed url="" %} ## Community tools that use Govtool APIs {% embed url="" %} {% embed url="" %} {% embed url="" %} {% embed url="" %} # Delegating How to delegate your Voting Power to a DRep Delegating is the act of 'loaning' your Voting Power - which equals ADA the balance in your wallet - to someone else. The person or organisation that you delegate to are called DReps, which is short for "Delegate Representatives". DReps represent you in a similar way as a parliamentary or congressional representative does in an analog government. Simply put, they vote on your behalf. You can also use your Voting Power with 'Automatic' voting options: These special options are for voting 'Abstain', or voting "No Confidence" on all proposals. These options are similar to DReps in that they vote for you. The main functions of Delegating: ### **Delegate to DRep** To delegate your personal Voting Power to someone else, who has registered previously as a dRep. ### **Signal No Confidence** Is where you use your Voting Power to Signal *'No confidence'*, in the constitutional committee, and also *vote 'no' on all proposals and vote 'yes' on all no-confidence proposals.* You would do this if you have lost confidence in the Constitutional Committee and want it to be replaced. ### **Vote ABSTAIN by default** This option will show that you have participated in Governance, but you are not supporting a yes or no vote on proposals. Your Voting Power, however, will count towards a quorum on all votes. # Delegate to a DRep How to delegate to a DRep 1. **Dashboard**\ From the dashboard, click the “View DRep Directory” button in the “Delegate your Voting Power” panel.
2. **Delegation Flow**\ In the next screen you have two options for delegation: You can delegate directly by clicking "Delegate" (2) below, or you can see more details of the DRep by clicking "View Details" (1). If you choose "View Details", you will be able to delegate as well from the subsequent page.
3. **Wallet Confirmation**\ Your will be need to sign the transaction in your wallet.
4. **Trasaction in progress**\ There will be a short wait while the tranaction gets onto the blockchain
5. **Delegation Complete**\ Once the transaction it's completed, the dashboard will show that you have delegated your Voting Power to a DRep. In the screen below, you can see that you have delegated your Voting Power and also the name and DRep ID that you've delegated to. You can change your delegation to another DRep, or to vote "Abstain" or No on all votes by clicking "Delegate to Another DRep".
# Abstain from Every Vote **Vote Abstain by default**. This option will show that you have participated in Governance, but you are not supporting a yes or no vote on proposals. Your Voting Power, however, will count towards a quorum on all votes. # Signal "No Confidence" on Every Vote This option is where you effectively use your Voting Power to have GovTool **Signal 'No confidence'**, in the constitutional committee, and also **vote 'NO' on all proposals and vote 'YES' on all no-confidence proposals**. You would do this if you have lost confidence in the Constitutional Committee and want it to be replaced. # Governance Actions Governance Actions are the core elements that make up governance on the blockchain. Anyone that has ADA in a wallet can propose a Governace Action. To submit a Governance Action, the submitter pays a refundable deposit of 100,000 Ada. The deposit will be returned automatically back to the submitter's wallet upon completion of the Voting period. ### Every governance action will include the following: * a deposit amount (recorded since the amount of the deposit is an updatable protocol parameter) * a reward address to receive the deposit when it is repaid * an anchor for any metadata that is needed to justify the action * a hash digest value to prevent collisions with competing actions of the same type (as described earlier) Governance Actions are covered in depth in [CIP-1694](https://www.1694.io/), which is the main defining document for governance on Cardano. You can read about the entirety of Cardano Governance in this document. ### To Submit a Governance Action on GovTool, you will need to: 1. Connect a wallet ([Compatible Wallets](/cardano-govtool/using-govtool/getting-started/compatible-wallets)) to GovTool that has at least 100,000 Ada plus a few extra Ada for transaction fees 2. Create a "Proposal" for the Governace Action [Propose a Governance Action](/cardano-govtool/using-govtool/governance-actions/propose-a-governance-action) 3. Store the metadata for your Governance Action yourself [Storing Information offline](/cardano-govtool/using-govtool/storing-information-offline). At this point, your Governance Action is in the Proposal stage. This is a forum for discussion and refinement, and is provided by GovTool to help users socialise and refine their proposed Actions if they so choose. 4. When you feel your Proposal is ready for a vote, Click the "Submit as a Governance Action" button. You will be asked to pay a deposit of 100,000 Ada, which will be automatically refunded to you when the Action has reached it's expiry date. # Types of Governance Actions There are seven types of Governance Actions. Follow the links below for a more complete explanation of each. | Governance Action | | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 1. [Motion of no-confidence](/cardano-govtool/using-govtool/governance-actions/types-of-governance-actions/motion-of-no-confidence) | | 2. [Update constitutional committee and/or threshold and/or term limits](/cardano-govtool/using-govtool/governance-actions/types-of-governance-actions/update-committee-or-threshold-or-term-limits) | | 3. [New Constitution or Guardrails Script](/cardano-govtool/using-govtool/governance-actions/types-of-governance-actions/new-constitution-or-guardrails-script) | | 4. [Hard-fork initiation](/cardano-govtool/using-govtool/governance-actions/types-of-governance-actions/hard-fork-initiation) | | 5. [Protocol parameter changes](/cardano-govtool/using-govtool/governance-actions/types-of-governance-actions/protocol-parameters-changes) | | 6. [Treasury withdrawal](/cardano-govtool/using-govtool/governance-actions/types-of-governance-actions/treasury-withdrawal) | | 7. [Info](/cardano-govtool/using-govtool/governance-actions/types-of-governance-actions/info-action) | # Motion of No Confidence ### A motion to create a *state of no-confidence* in the current Constitutional Committee. The constitutional committee is considered to be in one of the following two states at all times: 1. A normal state (i.e. a state of confidence) 2. A state of no-confidence In a *state of no-confidence*, the current committee is no longer able to participate in governance actions and must be replaced before any governance actions can be ratified. To pass, this Action requires:
Constitutional CommitteeDRepsSPOs
Doesn't Vote67%51%
These values could be changed via a new Government Action. To see the current values at any time, you can view . # Update Committee or Threshold or term limits ### Changes to the members of the constitutional committee and/or to its signature threshold and/or terms This action will have one or more of these data objects: * The set of verification key hash digests (members to be removed) * Members can be removed either singly or in multiples. * A map of verification key hash digests to epoch numbers (new members and their term limit) * New members can be added along with their term ending epoch dates * A fraction (new threshold) * The threshold for passing an Action can be changed To pass, this Action requires: #### Normal state of Constitution:
Constitutional CommitteeDRepsSPOs
Doesn't Vote67%51%
#### Constitution in state of No Conficence
Constitutional CommitteeDRepsSPOs
Doesn't Vote60%51%
These values could be changed via a new Government Action. To see the current values at any time, you can view . # New Constitution or Guardrails Script ### A modification to the Constitution or Guardrails Script, recorded as on-chain hashes This action will have one or more of these data objects: * An anchor to the Constitution * Optional script hash of the Guardrails Script To pass, this Action requires:
Constitutional CommitteeDRepsSPOs
Pass75%Doesn't vote
These values could be changed via a new Government Action. To see the current values at any time, you can view . # Hard Fork Initiation ### A non-backward compatible upgrade of the network, which requires a prior software upgrade This action will have: * The new (greater) major protocol version To pass, this Action requires:
Constitutional CommitteeDRepsSPOs
Pass60%51%
These values could be changed via a new Government Action. To see the current values at any time, you can view . Note: There are many varying definitions of the term "hard fork" in the blockchain industry. Hard forks typically refer to non-backwards compatible updates of a network. In Cardano, we formalise the definition slightly more by calling any upgrade that would lead to *more blocks* being validated a "hard fork" and force nodes to comply with the new protocol version, effectively obsoleting nodes that are unable to handle the upgrade. # Protocol Parameters changes ### Any change to **one or more** updatable protocol parameters, excluding changes to major protocol versions ('hard forks') There are four types of protocol parameter changes, however, changes are not restricted to any groupp. In case where a Governance Action carries updates for multiple parameters from different groups, the maximum threshold of all the groups involved will apply to any given such governance action. The four types of parameter changes: The **network group** consists of: * maximum block body size (`maxBlockBodySize`) * maximum transaction size (`maxTxSize`) * maximum block header size (`maxBlockHeaderSize`) * maximum size of a serialised asset value (`maxValueSize`) * maximum script execution units in a single transaction (`maxTxExecutionUnits`) * maximum script execution units in a single block (`maxBlockExecutionUnits`) * maximum number of collateral inputs (`maxCollateralInputs`) Ratification threshold for the **network group:**
Constitutional CommitteeDRepsSPOs
Pass60%51%
The **ecomomic group** consists of: * minimum fee coefficient (`txFeePerByte`) * minimum fee constant (`txFeeFixed`) * delegation key Lovelace deposit (`stakeAddressDeposit`) * pool registration Lovelace deposit (`stakePoolDeposit`) * monetary expansion (`monetaryExpansion`) * treasury expansion (`treasuryCut`) * minimum fixed rewards cut for pools (`minPoolCost`) * minimum Lovelace deposit per byte of serialized UTxO (`utxoCostPerByte`) * prices of Plutus execution units (`executionUnitPrices`) Ratification threshold for the **ecomomic group:**
Constitutional CommitteeDRepsSPOs
Pass67%Doesn't vote
The **technical group** consists of: * pool pledge influence (`poolPledgeInfluence`) * pool retirement maximum epoch (`poolRetireMaxEpoch`) * desired number of pools (`stakePoolTargetNum`) * Plutus execution cost models (`costModels`) * proportion of collateral needed for scripts (`collateralPercentage`) Ratification threshold for the **technical group:**
Constitutional CommitteeDRepsSPOs
Pass67%Doesn't vote
The **governance group** consists of all the new protocol parameters that are introduced in this CIP: * governance voting thresholds ( P 1 , P 2 a , P 2 b , P 3 , P 4 , P 5 a , P 5 b , P 5 c , P 5 d , P 6 , Q 1 , Q 2 a , Q 2 b , Q 4 , Q 5 ) * governance action maximum lifetime in epochs (`govActionLifetime`) * governance action deposit (`govActionDeposit`) * DRep deposit amount (`dRepDeposit`) * DRep activity period in epochs (`dRepActivity`) * minimal constitutional committee size (`committeeMinSize`) * maximum term length (in epochs) for the constitutional committee members (`committeeMaxTermLength`) Ratification threshold for the **governance group:**
Constitutional CommitteeDRepsSPOs
Pass67%Doesn't vote
These values could be changed via a new Government Action. To see the current values at any time, you can view . # Treasury Withdrawal ### Treasury withdrawals are sub-categorised into small, medium, or large and are determined by the amount of Lovelace to be withdrawn. This action will have: * A withdrawal address * A positive number of Lovelace To pass, this Action requires:
Constitutional CommitteeDRepsSPOs
Pass67%Don't vote
These values could be changed via a new Government Action. To see the current values at any time, you can view . # Info Action ### For informational purposes. This action that has no effect on-chain, other than an on-chain record. This action will have: * No on-chain data except for a record. To pass, this Action requires:
Constitutional CommitteeDRepsSPOs
Pass100%100%
These values could be changed via a new Government Action. To see the current values at any time, you can view . # View Governance Actions You can view all Governance Actions with or without connecting a wallet ## Starting from the Landing Page Click "Governance Actions" from the top menu.
## The Governance Actions Page Clicking on the outlined menu item above will bring you to the Governance Actions page: 1. Search box, enter any Governance Action ID, title, keyword, etc. 2. Filters for Governance Actions. You will be able to choose which categories of Actions you want to see. 3. Sort order. Clicking this will allow you to sort Governance Actions by date, and by most votes 4. Categories of Governance Actions. These are the major, pre-set categories of Actions. 5. "View Details" Click on this to see detailed info. 6. Horizontal navigation. Click the left or right arrows to see more proposals.

Governance Actions page

## The Governance Action detail page If you Click on "View Details", you will be taken to a detail screen for that particular proposal 1. Title 2. Governance Action type 3. Submitted and Expiry dates and epochs 4. Share button 5. Governance Action ID 6. Governance Action details 7. Vote tally

Governance Action detail page

# Propose a Governance Action Create and Submit a Proposal for Governance Action To be able to submit a proposal for Governance Action, you will need to connect your wallet to GovTool in order to verify your identity. Please follow the step by step guideline 1. Navigate to 2. Click "Connect to Propose"
3. Click "Proposals"
4. Click "Verify your identity"
5. Select your wallet and connect. 6. Click "Propose a Governance Action"
7. Click "Create new Proposal"
8. Please ensure that you fill in all the required fields. It is important to complete every mandatory section to proceed successfully.
9. Once you have filled in all the required fields, please click "Continue" to proceed to the next step.
10. Then click on "Submit"
10. Before submitting the proposal as a Governance Action, it is recommended to add a poll as a temperature check. To do this, click on "Add a poll."
11. After the poll has closed, you can submit the proposal as a Governance Action. # Vote on Governance Actions Review and vote on active Governance Actions To be able to vote, you will need to connect your wallet to GovTool, and register yourself as a DRep or a Direct Voter. Once you've done this, the dashboard will change to give you the option to view and vote on Governance Actions. 1. **Dashboard** Click on the "View and vote" button to see on-chain Governance Actions. *(You can also use the 'Governance actions' tab in sidebar)*
2. **Governance Actions Page** 1. Search box, type any text Governance Action ID 2. Links to sort actions that you have not voted on as of yet ("To Vote"), and ones that you have voted on ("Voted") 3. Main Categories of Governance Actions 4. Filters and Sort 5. GA Summary 6. Click "View Details and Vote" to see proposal, and vote
3. **Governance Action Detail Page** 1. Title of the Governance Action 2. Type of the Governance Action 3. The submission and expiry dates an epochs 4. Governance Action ID 5. Governance Action description 6. Share button 7. Voting buttons 8. "Show Votes" will show you the latest votes on this Action 9. "Provide context about your vote" lets you provide off-chain rationalisation about your vote. You will have to take responsibilty for storing this data yourself. **Governance Action Detail Page** This is where you can see all the details of any Governance Action.
4. **Voting**\ Choose "Yes", "No", or "Abstain"
5. **Wallet Confirmation** \ You will be asked to sign and confirm the transaction in your wallet.
6. **In-progress state**\ Your Vote transaction will be submitted to on-chain. The transaction could take a few seconds or minutes to be fully completed. An in-progress state will be shown to keep track of progresses.
7. **Vote fully submitted**\ Once the transaction it's completed, the page will refresh automatically. You have now voted on this Governance Action. # Change your Vote How to change your vote on a Governance Action 1. **To change your vote:** 1. Go to Governance Actions page, 2. Click on "Voted on my me" 3. Click on the "View Details" button on the Action that you want to change.
2. **Change your vote**
3. **Change Vote**\ Click on 'Change vote'
4. **STEP 4 - Wallet Confirmation**\ You will be asked to sign and confirm the transaction in your wallet.
5. **Vote changed**\ Once the transaction it's completed, the page will refresh automatically. You have now changed your vote on this Governance Action.
# Storing Information offline How to store information off-chain for Governance Actions, DRep registration, and Voting. Generally speaking, most data in Governance is stored off-chain, and is referenced by an on-chain url and hash. For more detailed information, please see [CIP-1694](https://www.1694.io/en) Off-chain data can be stored in many places, such as IPFS, a web URL, or repo site like GitHub. The URL that references the data has to be publicly readable. Here is an example of using GitHub for storing data for a Governance Action. Storing data for becoming a DRep is the same process. 1. Agree to store information and click "Continue
2. Your information will be packaged up in a .jsonld file. Click on the button with the filename in it, and save it to your computer.
3. If you don't have a github account, you will need to create one. Simply enter your email address and click "Sign up for GitHub.
4. Click "Continue
5. Create a password, click "Continue"
6. Create a github user name (must be unique on github).
7. GitHub will send you a confirmation code to your email inbox. Find it and enter it here.
8. You now have a new GitHub account. You must create a repository, so in the screen below: 1. Create a name for your repository 2. Make your repository public 3. Click "Create Repository"
9. Now you have a public GitHub repository of your own!. In the example below, the repository is called "Saver-saver". You will need to upload the data.jsonld file that you got from GovTool now. Click the link "uploading an existing file"
10. Upload the "data.jsonld" file to GitHub by drag-and-dropping it or choosing it from your computer. Click the "Commit changes" button. This will add your file to GitHub and put it in your repository.
11. After the file uploads, you will see it's name in the list below. Click on the file name (it is a link)
12. This will display the file contents. You now need to get a URL to paste into GovTool. To do this, click the "Raw" button above the code.
13. From the "Raw" view, copy out the URL in the address bar:
14. Return to GovTool, paste the URL into the URL field, and click "Submit"
15. You have now submitted your data. It may take a few minutes or seconds for GovTool to process it. # Verification for Budget Proposals, Proposals, and discussions ## What's this all about? GovTool has several layers of identification and security to help people user the Proposals areas. These are in place to help people participate in discussions, and to make sure that GovTool users can be securely verified by requesting a signed transaction with a connected wallet. ## Display Names GovTool uses Display Names as a simpler way to recognise a commenter in our discussion forums. To use the forums, it is currently mandatory to create a Display Name. GovTool does not require any personally identifiable information (such as a email address, etc) to create a Display Name. The Display Name needs to be created just once, and is not changeable once it's set. In other words, it is bound to the wallet that's attached. You will be asked to create a Display Name on the first time you either: * Create a Budget Proposal. * Create a Proposal for a Governance Action. * Participate in the discussion forums for Budget Proposals or Governace Action Proposals. ## Verification of users by signing transactions To enable GovTool to clearly identify users on the discussion forums and Proposal areas, the first time a user either proposes a new Budget or Governance Action Proposal, or participates in a discussion forum, they will be required to sign a transction in their wallet. This identification of the users persists for the length of the user session. In other words, if you close your browser and come back, it's likely that you will be asked for another signing to re-identify yourself. There is no charge for this. ## For DReps GovTool actualises a unique statue for DReps, in that they can comment on Budget Proposals and Governace Action Proposals with a DRep tag next to their comments. To enable this function, DReps must sign an additional transaction in their wallet to confirm their DRep key. DReps currently will be identified by their Display Name (see above) and not their DRep name in the comments. This is a limitation of the architecture of GovTool, and the GovTool team is looking for a way around this to display the DRep name instead. # Run GovTool Locally If you are interested in contributing or exploring GovTool in depth, you can do so via a lightweight MiniKube Cluster, running each of the associated services on localhost. Its available in the following repo # Getting Started ## Prerequisites * It is heavily advised that the repos for all the pillars of GovTool that you would like to deploy be forked into you own local copy. (Each section title links back to the parent repo, links can also be found in the README file of this repo) * After forking the repo it is recommended to have a look at the Check and Build workflows as these are used by the respective upstream repos to build the images used in production. [Build Workflow Links](https://app.gitbook.com/o/Prbm1mtkwSsGWSvG1Bfd/s/qBJxNzoywC55SZXT5Tv2/~/changes/107/cardano-govtool/run-govtool-locally/quick-links) * Each of the Upstream repos will use environment variables similar to those which are listed in the **env-vars.yaml** files for each respective pillar with the exception of the GovTool backend which will rely upon the **config.json** however for deployment purposes this will just need to be treated as a secret similar to how the env-vars.yaml files are * As this was designed to be run locally using a Minikube cluster it is advised to have Docker installed and a Minikube Image downloaded locally [Guide Links](https://app.gitbook.com/o/Prbm1mtkwSsGWSvG1Bfd/s/qBJxNzoywC55SZXT5Tv2/~/changes/107/cardano-govtool/run-govtool-locally/quick-links) ## Pillar Naming Conventions Throughout this Wiki section you may find multiple references to backend and frontend services for the sake of clarity the following will be true: * pdf backend will reference the GovTool Proposal Pillar * outcomes backend will reference the GovTool Outcomes Pillar * backend will reference the Core GovTool Backend * metadata will reference the Core GovTool Metadata Validation Backend * frontend will reference the Core GovTool Frontend UI # Setting up Your Ingress ## Prerequisites To expose your Minikube cluster and test your deployment of the services works as expected you will need to ensure that you have the Minikube ingress service enabled so you can access via the tunnel command. If issues occur using the default NodePort a patch can be applied to use either a LoadBalancer or ClusterIP using the following command `kubectl patch svc ingress-nginx-controller -n ingress-nginx -p '{"spec": {"type": ""}}'` ## Setting up Your Ingress If planning to run everything via localhost as is currently done in the example ingress provided there are some additional considerations required: 1. Edit your /etc/hosts file to ensure that your localhost (127.0.0.1) can resolve to the domains you plan to use e.g. be.localhost, oc.localhost, pdf.localhost 2. Install a root CA for you system to avoid any network certificate errors as the different services attempt to communicate with each other and create a tls certificate and key file for use with the cluster 3. The name space you will deploy your ingress service to (testing on multiple different Minikube images has proven that the default namespace is not suitable to have deploy the ingress and so may lead to issues) in the example file we have choose the govtool namespace which has been referenced in the yaml files for the other services 4. Make any desired modifications for the services and domains you which to test with 5. Use `kubectl apply` to start your ingress service # Core GovTool ## [Core GovTool](https://github.com/IntersectMBO/govtool) Core Govtool is comprised of the frontend, backend and metadata services which will allow you to view * Home, * Governance Actions Live Voting, * Drep Directory, * Guides * FAQs with or without a wallet connected ## Prerequisites To run Core GovTool you will need access to a **DB-Sync Instance**, this can be run locally or via a third party e.g. Demeter.\ This is a dependency of the backend service which will query the information stored in DB-Sync to retrieve and populate the respective pages with information checking for any issues using the Metadata Validation service ## Notice As the instance of [Cardano GovTool](https://gov.tools) uses a DB-Sync with which leverages some of the [insert options](https://github.com/IntersectMBO/cardano-db-sync/blob/13.6.0.4/doc/configuration.md#properties) available in the config file everything may not display identically when running locally e.g. 3rd party providers may not have access to the pool stat table meaning SPO voting may not shown/be accurate The Backend service heavily utilises the utxo\_view shipped as standard with db-sync, however in some instances, depending on the config used, it can encounter issues. Below are two examples of how this view can be re-created if required: 13.6.0.4 `CREATE OR REPLACE VIEW public.utxo_view AS SELECT tx_out.id, tx_out.tx_id, tx_out.index, address.address, address.has_script AS address_has_script, address.payment_cred, tx_out.stake_address_id, tx_out.value, tx_out.data_hash, tx_out.inline_datum_id, tx_out.reference_script_id, tx_out.consumed_by_tx_id FROM tx_out LEFT JOIN tx_in ON tx_out.tx_id = tx_in.tx_out_id AND tx_out.index::smallint = tx_in.tx_out_index::smallint LEFT JOIN tx ON tx.id = tx_out.tx_id LEFT JOIN address ON address.id = tx_out.address_id LEFT JOIN block ON tx.block_id = block.id WHERE tx_in.tx_in_id IS NULL AND block.epoch_no IS NOT NULL AND tx_out.consumed_by_tx_id IS NULL;` previous versions `CREATE OR REPLACE VIEW public.utxo_view AS SELECT tx_out.id, tx_out.tx_id, tx_out.index, tx_out.stake_address_id, tx_out.value, tx_out.data_hash, tx_out.inline_datum_id, tx_out.reference_script_id, tx_out.consumed_by_tx_id, tx_out.address_id FROM tx_out LEFT JOIN tx_in ON tx_out.tx_id = tx_in.tx_out_id AND tx_out.index::smallint = tx_in.tx_out_index::smallint LEFT JOIN tx ON tx.id = tx_out.tx_id LEFT JOIN block ON tx.block_id = block.id WHERE tx_out.consumed_by_tx_id is NULL AND tx_in.tx_in_id IS NULL AND block.epoch_no IS NOT NULL;` ## Setting up Core GovTool 1. Review the frontend -> fe-env-vars.yaml and the backend -> config.json files and add your custom env vars 2. Review [frontend.yaml](https://github.com/aaboyle878/govtool-k8-manifest/blob/6f297e580250882dcefcfbef4f4abcbf56a6ead4/govtool/mainnet/frontend/frontend.yaml), [backend.yaml](https://github.com/aaboyle878/govtool-k8-manifest/blob/6f297e580250882dcefcfbef4f4abcbf56a6ead4/govtool/mainnet/backend/backend.yaml) and [metadata.yaml](https://github.com/aaboyle878/govtool-k8-manifest/blob/6f297e580250882dcefcfbef4f4abcbf56a6ead4/govtool/mainnet/metadata/metadata.yaml) ensuring to update the Deployment Containers Image Spec ([example](https://github.com/aaboyle878/govtool-k8-manifest/blob/6f297e580250882dcefcfbef4f4abcbf56a6ead4/govtool/mainnet/frontend/frontend.yaml#L34)) with the associated image for the service (these can be custom or the images referenced in the current deployments) and metadata -> namespace ([example](https://github.com/aaboyle878/govtool-k8-manifest/blob/6f297e580250882dcefcfbef4f4abcbf56a6ead4/govtool/mainnet/frontend/frontend.yaml#L5)) if not using the default govtool namespace 3. Create the Kubernetes Secrets which will house the env vars using `kubectl apply` and `kubectl create secret` (this will be used with the [config.json](https://github.com/aaboyle878/govtool-k8-manifest/blob/6f297e580250882dcefcfbef4f4abcbf56a6ead4/govtool/mainnet/backend/config.json)) in your chosen namespace 4. Use `kubectl apply` to launch the frontend backend and metadata services in the same namespace as your secrets -- ([kubectl links](https://app.gitbook.com/o/Prbm1mtkwSsGWSvG1Bfd/s/qBJxNzoywC55SZXT5Tv2/~/changes/107/cardano-govtool/run-govtool-locally/quick-links)) # Proposal Pillar ## [Proposal Pillar](https://github.com/IntersectMBO/govtool-proposal-pillar) The Proposal Pillar backend when combined with the Core GovTool Frontend UI will enable viewing of Budget Proposals and Governance Actions -> Proposals areas ## Prerequisites * As the proposal pillar was designed for off-chain discussion it will require a Postgres DB to store any user discussion information ## Notice * As stated above because this service covers off chain discussions when initially launched the DB will be empty and so there will be nothing to load when the respective pages are accessed from the frontend UI * As this repo was designed for dev purposes only the db has not been assigned any persistent storage (if running long term this will need to be updated) ## Setting Up the Proposal Pillar * Review the [pdf-db-connect.yaml](https://github.com/aaboyle878/govtool-k8-manifest/blob/6f297e580250882dcefcfbef4f4abcbf56a6ead4/govtool/mainnet/pdf/pdf-db-connect.yaml) and [pdf-env-vars.yaml](https://github.com/aaboyle878/govtool-k8-manifest/blob/6f297e580250882dcefcfbef4f4abcbf56a6ead4/govtool/mainnet/pdf/pdf-env-vars.yaml) files adding your custom env vars * Review [pdf-db.yaml](https://github.com/aaboyle878/govtool-k8-manifest/blob/6f297e580250882dcefcfbef4f4abcbf56a6ead4/govtool/mainnet/pdf/pdf-db.yaml) and [pdf.yaml](https://github.com/aaboyle878/govtool-k8-manifest/blob/6f297e580250882dcefcfbef4f4abcbf56a6ead4/govtool/mainnet/pdf/pdf.yaml) ensuring to update the [Deployment Containers Image Spec](https://github.com/aaboyle878/govtool-k8-manifest/blob/6f297e580250882dcefcfbef4f4abcbf56a6ead4/govtool/mainnet/pdf/pdf.yaml#L34) with the associated image for the service (these can be custom or the images referenced in the current deployments) and [metadata -> namespace](https://github.com/aaboyle878/govtool-k8-manifest/blob/6f297e580250882dcefcfbef4f4abcbf56a6ead4/govtool/mainnet/pdf/pdf.yaml#L5) if not using the default govtool namespace * Create the Kubernetes Secrets which will house the env vars using `kubectl apply` in your chosen namespace * Use `kubectl apply` to first create the pdf db and then pdf service in the same namespace as your secrets -- ([kubectl links](https://app.gitbook.com/o/Prbm1mtkwSsGWSvG1Bfd/s/qBJxNzoywC55SZXT5Tv2/~/changes/107/cardano-govtool/run-govtool-locally/quick-links)) # Outcomes Pillar ## [Outcomes Pillar](https://github.com/IntersectMBO/govtool-outcomes-pillar) The Governance Actions Outcomes Pillar backend when combined with the Core GovTool Frontend UI will enable viewing of the Governance Actions -> Outcomes section ## Prerequisites * This service will also need to access a db-sync instance to successfully retrieve any Governance Actions that have been raised in the past * A valid IPFS Gateway will also need to be passed as an env var to the service to ensure the metadata associated with the Governance Action can be displayed ## Notice As the instance of [Cardano GovTool](https://gov.tools) uses a DB-Sync with which leverages some of the input options available in the config file everything may not display identically when running locally e.g. 3rd party providers may not have access to the pool stat table meaning SPO voting may not show/be accurate ## Setting Up the Outcomes Pillar * Review [oc-env-vars.yaml](https://github.com/aaboyle878/govtool-k8-manifest/blob/6f297e580250882dcefcfbef4f4abcbf56a6ead4/govtool/mainnet/outcomes/oc-env-vars.yaml) and add your custom env vars * Review [outcomes.yaml](https://github.com/aaboyle878/govtool-k8-manifest/blob/6f297e580250882dcefcfbef4f4abcbf56a6ead4/govtool/mainnet/outcomes/outcomes.yaml) ensuring to update the [Deployment Containers Image Spec](https://github.com/aaboyle878/govtool-k8-manifest/blob/6f297e580250882dcefcfbef4f4abcbf56a6ead4/govtool/mainnet/outcomes/outcomes.yaml#L34) with the associated image for the service (these can be custom or the images referenced in the current deployments) and [metadata -> namespace](https://github.com/aaboyle878/govtool-k8-manifest/blob/6f297e580250882dcefcfbef4f4abcbf56a6ead4/govtool/mainnet/outcomes/outcomes.yaml#L5) if not using the default govtool namespace * Create the Kubernetes Secrets which will house the env vars using `kubectl apply` in your chosen namespace * Use `kubectl apply` to launch the outcomes pillar in the same namespace as your secrets -- ([kubectl links](https://app.gitbook.com/o/Prbm1mtkwSsGWSvG1Bfd/s/qBJxNzoywC55SZXT5Tv2/~/changes/107/cardano-govtool/run-govtool-locally/quick-links)) # Quick Links ### Build Workflows * [Core Govtool](https://github.com/IntersectMBO/govtool/blob/bdea53d06e3b65a4f2531551c8201db2db3681ce/.github/workflows/build-from-main.yml) * [Proposal Pillar](https://github.com/IntersectMBO/govtool-proposal-pillar/blob/0bc51ed9051965291340b21e4f2df368eb54e20b/.github/workflows/merge.yaml) * [Outcomes Pillar](https://github.com/IntersectMBO/govtool-outcomes-pillar/blob/5a9542b8c521e93524c0d198984d7c2135509a59/.github/workflows/build-backend-image.yaml) ### Docker Desktop Installation * [Mac](https://docs.docker.com/desktop/setup/install/mac-install/) * [Windows](https://docs.docker.com/desktop/setup/install/windows-install/) * [Linux](https://docs.docker.com/desktop/setup/install/linux/) ### [Minikube Installation](https://minikube.sigs.k8s.io/docs/start/?arch=%2Fmacos%2Farm64%2Fstable%2Fbinary+download) ### Kubectl Commands * [Create Namespace](https://kubernetes.io/docs/reference/kubectl/generated/kubectl_create/kubectl_create_namespace/) * [Create Secret](https://kubernetes.io/docs/reference/kubectl/generated/kubectl_create/kubectl_create_secret/) * [Apply File](https://kubernetes.io/docs/reference/kubectl/generated/kubectl_apply/) * [Patching](https://kubernetes.io/docs/reference/kubectl/generated/kubectl_patch/) # FAQs # How Governance Action Vote Totals are Calculated in GovTool ## DRep Vote Total Equation GovTool aims to show vote total values which help the user gauge likelihood of ratification of an action. ### Intro definitions * Active DRep stake = all the voting power of DReps within the active state * (This does not include any in-active DReps OR retired DReps) * Total Active Stake = Active DRep stake + auto no confidence stake * We do not include any abstain within this, as they are not part of ratification equation ### For a governance action #### :thought\_balloon: Abstain Total * Total voting power of DRep Abstain votes + auto-abstain stake #### :white\_check\_mark: Yes Total * IF governance action type != 'NoConfidence' * Total of voting power of DReps Yes votes * IF governance action type == 'NoConfidence' * Total of voting power of DReps Yes votes + auto no confidence stake #### :white\_check\_mark: Yes Percentage * (Yes Total / Total Active Stake) x 100 #### :x: No Total * IF governance action type != 'NoConfidence' * Total of voting power of DReps No votes + auto no confidence stake * IF governance action type == 'NoConfidence' * Total of voting power of DReps No votes #### :x: No Percentage * (No Total / Total Active Stake) x 100 #### :ballot\_box: Not Voted Total (remainder of Total Active Stake) * Total Active Stake - Yes Total - No Total #### :ballot\_box: Not Voted Percentage (remainder of Total Active Stake Percentage) * 100 - yes percentage - no percentage * this should equal ((Total Active Stake - Yes Total - No Total) / Total Active Stake ) \* 100 ## DRep Vote Total Implementation [See GovTool's SQL query](https://github.com/IntersectMBO/govtool/blob/develop/govtool/backend/sql/list-proposals.sql) run on DB-Sync. This pulls all the proposal data, and vote totals. * GovTool takes DRep voting power from [`drep_distr` table of DB-Sync](https://github.com/IntersectMBO/cardano-db-sync/blob/master/doc/schema.md#drep_distr) for the registered DReps and the "predefined voting option DReps", this data is only updated once per epoch. * GovTool takes the newest vote from DReps for that governance action, filtering out votes from DReps who have recently retired. * In the SQL query * [Gets the latest epoch of DRep distribution](https://github.com/IntersectMBO/govtool/blob/develop/govtool/backend/sql/list-proposals.sql#L1-L7) * [Gets the voting power of the predefined no confidence DRep](https://github.com/IntersectMBO/govtool/blob/develop/govtool/backend/sql/list-proposals.sql#L18-L26) * [Gets the voting power of the predefined always abstain DRep](https://github.com/IntersectMBO/govtool/blob/develop/govtool/backend/sql/list-proposals.sql#L18-L26) * [Calculates Yes Total](https://github.com/IntersectMBO/govtool/blob/develop/govtool/backend/sql/list-proposals.sql#L242-L247) * [Calculates No Total](https://github.com/IntersectMBO/govtool/blob/develop/govtool/backend/sql/list-proposals.sql#L248-L253) * [Calculates Abstain Total](https://github.com/IntersectMBO/govtool/blob/develop/govtool/backend/sql/list-proposals.sql#L254) ### Example * So we have some DRep John Doe, who voted `yes` on X governance action * John Doe has 100k Voting power coming from his own stake and all delegators (we are taking that value directly from db-sync (no calculations on GovTool side)) * We have another DRep - Andre, who has 200k Voting power! * Andre also likes the governance action and votes `yes` * As a result - we display the sum of their voting powers, so it would be 300k for `yes` votes * Important note - John Doe and Andre can change their votes ## SPO Vote Totals * For SPOs logic is completely the same as the DReps one - the difference is that we are taking the voting power from a different table - dedicated to SPOs (`pool_stat`) # Ways to use your Voting Power Using your voting power allows you to participate in Cardano Governance. Every ADA holder has an amount of Voting Power equal to the amount of Lovelace they have in a wallet. When you link a wallet containing ADA to GovTool, GovTool will read the ADA balance in the wallet, and make it available to you to use as Voting Power. Voting Power can be used in several ways: * Delegate your Voting Power to a DRep.[ How to delegate your Voting Power](/cardano-govtool/using-govtool/delegating/delegate-to-a-drep) * Delegate your Voting Power to "[Abstain](/cardano-govtool/using-govtool/delegating/abstain-from-every-vote)" or "[Signal No Confidence](/cardano-govtool/using-govtool/delegating/signal-no-confidence-on-every-vote)". These effectively instruct GovTool to cast these votes on every Governance Action on your behalf. These options work like DReps, and they apply to every Governance Action that comes up for a vote. * Become a Direct Voter and Vote on Governance Actions by yourself. [How to become a Direct Voter](/cardano-govtool/using-govtool/direct-voting) * Become a DRep and Vote on Governance Actions with your own Voting Power and Voting Power shared with you by other users. [How to become a DRep](/cardano-govtool/using-govtool/dreps/register-as-a-drep) # Direct Voter vs DRep What is the difference? Direct voters are a concept that GovTool adds on top of the on-chain DRep mechanism. Direct Voters are not explicitly supported by the protocol but are instead an abstraction over the on-chain DReps. Like DReps a Direct Voter is someone that can vote on any Governance Action with their own Voting Power. They do not wish to campaign for delegations from others or be shown via the DRep Directory. GovTool considers (on-chain) DReps who do not wish to attach metadata to their DRep as Direct voters. The rationale being, those who wish to vote but not represent others are unlikely to want to attach metadata to their registration. They do not wish to be a 'representative'. Other tools likely show Direct Voters as DReps, as on-chain they are. The idea of a direct voter came out of user tests for GovTool, where calling everyone who just wants to vote a 'delegated representative' caused much confusion. Direct voter concept aims to reduce the potential for this confusion. # What does it mean to register as a DRep? [Delegated Representatives (DReps) ](/cardano-govtool/faqs/what-is-a-drep)are like 'parlimentary representatives' in the Governance system. DReps can have other ADA holders to delegate their voting power to them, which allows DReps to vote by proxy using the accumulated Voting Power of all their delegators. \ \ Any ADA holder can become a DRep. They simply need to register on GovTool (or other platform). [Read about how to become a DRep](/cardano-govtool/using-govtool/dreps/register-as-a-drep) # What is a Governance Action? #### Note: This content is taken directly from [CIP-1694](https://www.1694.io/) We define seven different types of **governance actions**. A governance action is an on-chain event that is triggered by a transaction and has a deadline after which it cannot be enacted. * An action is said to be **ratified** when it gathers enough votes in its favor (through the rules and parameters that are detailed below). * An action that fails to be ratified before its deadline is said to have **expired**. * An action that has been ratified is said to be **enacted** once it has been activated on the network. | Action | Description | | ------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------ | | 1. Motion of no-confidence | A motion to create a *state of no-confidence* in the current constitutional committee | | 2. New constitutional committee and/or threshold and/or terms | Changes to the members of the constitutional committee and/or to its signature threshold and/or terms | | 3. Update to the Constitution or proposal policy | A modification to the Constitution or proposal policy, recorded as on-chain hashes | | 4. Hard-Fork2 Initiation | Triggers a non-backwards compatible upgrade of the network; requires a prior software upgrade | | 5. Protocol Parameter Changes | Any change to **one or more** updatable protocol parameters, excluding changes to major protocol versions ("hard forks") | | 6. Treasury Withdrawals | Withdrawals from the treasury | | 7. Info | An action that has no effect on-chain, other than an on-chain record | **Any Ada holder** can submit a governance action to the chain. They must provide a deposit of `govActionDeposit` Lovelace, which will be returned when the action is finalized (whether it is **ratified** or has **expired**). The deposit amount will be added to the *deposit pot*, similar to stake key deposits. It will also be counted towards the stake of the reward address it will be paid back to, to not reduce the submitter's voting power to vote on their own (and competing) actions. If a proposal policy is present, the transaction must include that policy in the witness set either directly, or via reference inputs, and any other requirements that the proposal policy makes must be satisfied. Note that a motion of no-confidence is an extreme measure that enables Ada holders to revoke the power that has been granted to the current constitutional committee. # What is a DRep? Delegated Representatives (DReps) are ADA holders who registered on-chain to allow other members of the community to delegate their voting power to them, so that they can vote on their behalf. They are are like 'parlimentary representatives' in the Governance system. DReps are defined by [CIP-1694](https://www.1694.io/). They can: * Submit Governance Actions * Review and submit votes on active Governance Actions * Accept delegated Voting Power from any ADA holder When a DRep votes on a Governance Action, they vote with all the [Voting Power](/cardano-govtool/faqs/what-is-voting-power) that is delegated to them. # What is Voting Power? For ada holders voting power refers to the amount of ada they own. For registered DReps Voting Power refers both to the voting power they own and to the voting power that other ada holders have delegated to them. Voting Power is calculated at the end of every epoch. When a Voter casts a Vote in GovTool, the Votes are also tallied only at epoch boundaries. # Bootstrapping phase ### What is the bootstrapping phase? The technical bootstrapping phase is a temporary state of governance as described in [CIP-1694 Bootstrapping Phase](https://github.com/cardano-foundation/CIPs/blob/master/CIP-1694/README.md#bootstrapping-phase). Within this state only a limited set of governance features are enabled by the network. ### What are the implications of bootstrapping on GovTool? #### Ada Holders * Are able to register as DReps/ direct voters * Are able to delegate to DReps * Are **ONLY** able to propose and submit Info actions via GovTool #### DReps/Direct Voters * DReps are able to register. * Voting is restricted to Info Actions **ONLY**. #### All Users * The ONLY types of governance actions viewable on-chain are * Info Actions * Hard Fork Initiations * Parameter changes # How was the author of Withdraw ₳45,217 for MLabs Core..." GA Verified? {% hint style="info" %} Governance action ID gov\_action18nefry4qacd80xzs2srjahxm2e4vz3c8wvrr03rrtk8mdqfuknysq66459t {% endhint %} ## Context: A metadata formatting issue caused only part of the data to be signed, preventing automatic verification — the signature is valid and can be manually confirmed.\ Govtool builders have manually verified the signature confirming this Treasury action is genuinely coming from Intersect and has marked it accordingly to make it explicit to DReps. *Related X Post about Cardano Signer* ## How to manually check the signature? * * * {% embed url="" %}
# Constitutional Committee Portal Functions Everyone using the Constitutional Committee Portal can do the following things: * Read the Interim Constitution, including navigation using the table of contents sidebar and see how the current constitution differs from previous iterations. * View membership of the Interim Constitutional Committee (ICC), See who is a member of the ICC and some details about them. * See how members of the ICC have voted and their rationale for doing so (if available). # Read the Interim Constitution https\://constitution.gov.tools/en/interim-constitution The Constitutional Committee Portal is the place to view the most up to date in-force copy of the Cardano Constitution (currently showing the Interim Constitution). In addition to the constitution you can use a table of contents in the sidebar, which allows you to navigate between sections of the Interim Constitution.
# Compare Constitution Iterations https\://constitution.gov.tools/en/interim-constitution Another feature is to compare the current constitution with previous versions of the constitution, to see what has changed.
# View Interim Constitutional Committee Members https\://constitution.gov.tools/en/members This displays the members of the ICC who have registered with the Constitutional Committee Portal along with a short description of each one.
# View Interim Constitutional Committee Members have votes https\://constitution.gov.tools/en/latest-updates Navigating to the Latest Updates page using the navigation bar, will show you a list of votes made by the ICC members who are registered on the Constitutional Committee Portal. Displaying: * The name and picture of the ICC member * The vote transaction ID * The title of the governance action (if available) * The type of governance action * How the member voted ("YES"/ "NO"/ "ABSTAIN") * The rationale posted by the ICC member (if available) You can also select "Show more" to have a closer look at the rationale posted by the ICC member (if available)
# How to suggest a feature or submit an idea If you want to suggest a feature or idea, click on the 'feedback' button at the bottom of your screen, click 'idea' and follow the guide. * **STEP 1**\ Click on the 'Feedback' button
* **STEP 2**\ Select 'Idea or new feature'
* **STEP 3**\ Provide details like name of the idea or new feature, text or an attachment
* **STEP 4**\ Submit your feedback
# How to submit a bug First check against list of [Known Issues](/overview/system-status). If you find a bug click on the 'feedback' button at the bottom of the your screen, select 'bug' and follow the guide. 1. **STEP 1**\ Click on the 'Feedback' button
2. **STEP 2**\ Select 'Report an issue'
3. **STEP 3**\ Provide details: 1. Text description of the bug or issue 2. You can add a screenshot, or video 3. Click "Submit"
# Overview The Cardano governance tools are fully open-sourced with an Apache 2.0 license. This ensures these tools are owned and maintained by the Cardano community itself via Intersect committees and working groups. Contracts for core maintainers are in place to ensure the Cardano GovTool and the Constitutional Committee Portal (the core governance tools) are fully supported and maintained and to ensure contribution to those is easy for individuals. The current maintainers are: * [Byron Network](https://www.linkedin.com/company/byron-network/): Cardano GovTool Voting and Delegation pillar * [DQuadrant](https://www.linkedin.com/company/dquadrant/): Cardano GovTool end-to-end testing * [Bloxico](https://www.linkedin.com/company/bloxico/): Constitutional Committee Portal * [WeDeliver](https://www.linkedin.com/company/we-deliver-it/): Cardano GovTool Proposal discussion pillar * [Lido Nation](https://www.lidonation.com/en): Cardano GovTool Outcomes pillar # How to participate This page shows different ways to participate in the development and improvement of the Cardano governance tools To participate you have different options: * You can submit feedback on bugs and ideas via the feedback button on gov.tools and on constitution.gov.tools, see [How to suggest a feature](/bugs-or-feature-suggestions/how-to-suggest-a-feature-or-submit-an-idea). * You can join the Intersect Governance Tools working groups, to join this, simply [become a free associate](https://members.intersectmbo.org/registration) of Intersect and find the working group in the Intersect discord server. * You can contribute directly to the [open repositories](/participate-in-development/governance-tools-repositories). * You can integrate with the [Proposal Discussion Open API](/participate-in-development/govtool-apis/proposal-pillar-api). # Governance Tools Repositories ## GovTool ### Wrapper * [GovTool (Voting and delegation)](https://github.com/IntersectMBO/govtool) ### Pillars * [Voting Pillar](https://github.com/IntersectMBO/govtool-voting-pillar) * [Delegation Pillar](https://github.com/IntersectMBO/govtool-delegation-pillar) * [Proposal Pillar](https://github.com/IntersectMBO/govtool-proposal-pillar) * [Outcomes Pillar](https://github.com/IntersectMBO/govtool-outcomes-pillar) ## Constitutional Committee Portal * [Constitution Committee Portal](https://github.com/IntersectMBO/cc-portal) # Govtool APIs Voting and delegation pillars APIs Outcomes APIs Proposal Discussion and Budget proposals APIs [Proposal Pillar API](/participate-in-development/govtool-apis/proposal-pillar-api) # Proposal Pillar API GovTool's backend services are primarily focussed on reading governance data from Cardano, and showing this to users. Although the APIs for these services are open with a general policy builders are not encouraged to use these, as these are specialised for GovTool and maybe changed without notice. GovTool's Proposal Discussion Pillar is an off-chain forum, to discuss and propose ideas that may become governance actions. This off-chain data is generated by GovTool and cannot be queried by chain indexing. This is why Intersect/GovTool commits to allowing builders/tooling providers to use the Proposal Pillar API. ### Data Access and Use Policy TBD # Access In repo API documentation for the Proposal Backend: ### API Access * [Swagger Documentation](https://p1337-z74f91f2d-zb0719f09-gtw.z937eb260.rustrocks.fr/api-docs#tag/Proposal/operation/Update%20proposal) * Work in progress (includes Budget Proposals): * After its completed, [Swagger Documentation](https://docs.intersectmbo.org/intersect-knowledge-base) above will be updated * Mainnet: {end-point} * Preview: