KIP-12: Security Council Elections

Active Proposals
1

KIP Type:

Constitutional KIP

Abstract:

This proposal recommends the adoption of WinVote.io as the on-chain election platform for Security Council elections within the KARRATco. WinVote is already used for all other KARRATco governance proposals, and extending its utility to include elections ensures that all on-chain governance functions remain within a single, unified system. However, WinVote does not currently support election functionality. To enable this, a development window of up to six months is required. As such, this proposal also requests delaying the upcoming Security Council election from April 15, 2025 to October 15, 2025 to accommodate the necessary work.

This proposal also introduces a revised election timeline, consolidating the process into two clear phases that align with the existing KARRATco governance flow. This new structure—built around WinVote’s standard proposal lifecycle—simplifies execution, ensures compatibility with the Governor contract, and improves clarity for participants. These combined updates are designed to deliver a smooth, secure, and scalable election process in alignment with the KARRATco Constitution.

Motivation:

The KARRATco Constitution specifies that Security Council elections may only begin once an approved and installed on-chain election process is in place. While WinVote.io is already the platform of record for governance within the KARRATco—supporting proposal creation, voting, and execution—it currently lacks support for elections.

Introducing a separate tool solely for Security Council elections would fragment the governance process, increase complexity for users, and create inconsistencies across systems. By extending WinVote’s functionality to support elections, KARRATco can preserve governance coherence, improve voter experience, and maintain a secure, unified on-chain record of decision-making.

Additionally, this proposal introduces a simplified, two-phase election timeline that fully aligns with the existing Governor contract. This change eliminates unnecessary complexity from the current multi-step structure, making the election process easier to understand and implement. Each phase follows a familiar lifecycle—temperature check, voting, timelock, and implementation—streamlining participation while preserving constitutional intent. This approach also reduces engineering overhead by building on tested systems already trusted by the also reduces engineering overhead by building on tested systems already trusted by the community.

Rationale:

WinVote.io is already the trusted governance platform for KARRATco and has demonstrated stability, transparency, and strong community adoption. Expanding its capabilities to include Security Council elections avoids the need for an additional tool, reduces fragmentation, and strengthens consistency across all governance activities.

The newly proposed two-phase election structure mirrors the established WinVote proposal lifecycle and requires no new governance logic to be introduced. This ensures full compatibility with the existing Governor contract and allows the election process to be implemented with minimal disruption. By aligning the Security Council elections with the same process used for standard proposals, participation becomes more intuitive and accessible for the community.

From both a technical and user experience standpoint, this streamlined structure simplifies execution, reduces the risk of confusion, and lowers the burden on both voters and developers—while fully satisfying the constitutional requirement for an on-chain election process.

Overview:

This proposal introduces two core updates to the Security Council election process within the KARRATco:

  1. Platform Selection: The KARRATco currently uses WinVote.io as its primary governance tool. This proposal recommends extending that use to include Security Council elections, ensuring all on-chain governance takes place within a single, familiar environment. Although WinVote currently does not support election-specific functionality, its modular design makes it well-suited for this expansion. A development timeline of up to six months is required to build, test, and audit the necessary features. As such, this proposal also recommends delaying the next Security Council election from April 15, 2025 to October 15, 2025.

  2. Revised Election Structure: To simplify participation and align with the existing Governor contract, this proposal introduces a two-phase election process, each following the standard WinVote governance flow. This new structure reduces operational complexity while preserving the intent and integrity of the original election model described in the KARRATco Constitution.

Collection of Potential Contenders:

A post on Discourse/Forum (forum.karratcoin.com) will be submitted by the Karrat Foundation, calling for all members who are interested in becoming a Security Council member. This Discourse post will be actively monitored for 1 week. To be a Potential Contender, you must engage with the discourse post, state your interest to be a Security Council member and list your wallet address containing at least 100,000 KARRAT. It will be verified during the process that you own these tokens.

Phase 1: Contender Submission

This phase opens the floor to any KARRATco member who wishes to be considered for the Security Council.

  • Temperature Check (1 week): Community discussion on Snapshot regarding potential contenders.

  • Formal Call for Voting / Pending Period (3 days): Governance-required delay before the vote becomes active.

  • KARRATco Voting (14 days): Members vote on contenders. The top 6 contenders who receive the most votes move forward to Phase 2 as Candidates, pending a KYC check done by the Karrat Foundation.

  • Timelock (7 days): Standard governance delay.

  • Implementation: Official recognition of Candidates.

KYC Check:

Prior to Phase 2 beginning. A KYC of the 6 contenders will be performed by the Karrat Foundation. If a contender does not pass KYC to become a candidate, the contender with the next most votes will take their place in Phase 2. Phase 2 will not begin until all KYC is processed and passed by 6 candidates.

Phase 2: Voting for Candidate Selection

This phase determines the final three Security Council members.

  • Temperature Check (1 week): Snapshot discussion focused on Candidates.

  • Formal Call for Voting / Pending Period (3 days): Pre-vote delay.

  • KARRATco Voting (14 days): Members vote. The top three candidates who have received at least 0.2% of all Votable Tokens are elected to the Security Council. In the event that the candidates do not receive at least 0.2% of all Votable Tokens, sitting Security Council members will stay in place until the next election takes place. If only 1 or 2 members receive the appropriate number of votes, the Foundation will make the determination on which sitting Security Council members will be retained until the next election.

  • Timelock (7 days): Standard delay.

  • Implementation: On-chain installation of newly elected Council members.

This structure prioritizes clarity, compatibility, and ease of execution—making the election process more accessible to the community while fully utilizing the tools and governance logic already in place.

Specifications and Timelines:

To enable Security Council elections within WinVote.io, the following components must be designed, developed, and validated. The estimated timeline for this work is up to six months, accounting for engineering, integration, and security requirements.

1. Smart Contract Development (2 months)

  • Extend existing Governor contracts or develop modular election-specific logic to support multi-phase voting and candidate progression.

  • Ensure compatibility with token-weighted voting and all current KARRATco governance standards.

  • Include logic to track vote thresholds, promote contenders to candidates, and install final elected Council members.

2. Front-End Integration (1 month)

  • Build intuitive, user-facing flows for contender submission, candidate tracking, and voting—matching the existing KIP interface experience.

  • Ensure accessibility for all KARRATco members with clear phase indicators and real-time voting transparency.

3. Back-End + Snapshot Integration (1 month)

  • Integrate with Snapshot for Temperature Check phases in both election windows.

  • Ensure secure data transfer from Snapshot to WinVote for formal voting stages.

  • Provide admin tools for the KARRAT Foundation Moderators to manage nominee progression and validate participation.

4. Security Auditing (1–2 months)

  • Submit all election-related smart contracts for independent third-party security audits.

  • Address any vulnerabilities or edge cases identified through testing.

  • Conduct follow-up review prior to mainnet deployment.

5. Governance Simulation & Testing (2–4 weeks, overlapping with audit)

  • Run testnet simulations of the full two-phase election process.

  • Include contingency cases (e.g., ties, vote manipulation attempts, invalid candidates).

  • Validate vote progression, state changes, and successful on-chain installation.

This development window ensures that the Security Council election process is fully aligned with KARRATco’s governance infrastructure—prioritizing security, clarity, and ease of use.

Overall Cost:

All costs associated with the development, integration, and auditing of the Security Council election functionality within WinVote.io will be fully funded by the Karrat Foundation Treasury. This includes engineering work, front-end development, Snapshot integration, smart contract audits, and all necessary platform enhancements to support the new election process.

No funding or resources will be requested from the KARRATco Treasury for this initiative.

2

I do not support delaying the Security Council election simply because the Foundation failed to prepare the election infrastructure in time.

The date of the first election — April 15, 2025 — has been clearly defined in the KARRAT DAO Constitution since day one. That timeline wasn’t a suggestion, it was a commitment to the community. Waiting until the last minute to address tooling is either negligence or intentional delay, and neither should be rewarded with a term extension.

This DAO was built on principles of decentralization, transparency, and accountability. Delaying a constitutional process because internal responsibilities weren’t handled in time sets a terrible precedent.

I’m ready to run. Others are ready to vote. The DAO is ready to grow.
Let’s respect the Constitution — and the community — by keeping the election on schedule.

3

To the KARRATco

We have heard your feedback in regards to the proposed Security Council election and concerns about the timeline and want to take a moment to clarify the reasoning behind it, as well as address suggestions to switch to a different governance platform like Tally.

Why the 6-Month Window Exists (Platform-Agnostic Reality)

Whether we use WinVote, Tally, or another governance platform, there are core technical requirements that must be met in order to run a secure and compliant on-chain election. These include:

  • Smart contract development to handle multi-phase election logic
  • Snapshot + backend integration to manage nomination visibility, off-chain temperature checks, and vote coordination
  • A full third-party audit to ensure the integrity of the system before mainnet deployment

These are non-optional components, and together they create a realistic delivery window of 3–5 months. Why the range? Because development is not binary. Things often don’t go perfectly, unexpected edge cases, integration hurdles, or security concerns can (and do) emerge, especially with new systems.

If a different platform like Tally were used, the only step that gets removed is the time required to integrate the front-end UI into WinVote. All other work such as the smart contract development, integration, testing, and auditing, still needs to occur. So in practice, the time savings would be marginal, while other trade-offs would be introduced.

Constraints Related to Tally vs Winvote

Tally is a solid governance platform but it comes with trade-offs which we have previously encountered:

  • There can be significant costs for anything beyond their free tier
  • There can be unclear implementation timelines when asking for features not currently supported in their free tier, or for any customization
  • Past experience with Tally showed us that key features like managing multiple quorums (e.g., Constitutional vs Non-Constitutional) required both months of development and tens of thousands of dollars in cost to the Tally platform, with months of waiting time too.

These challenges are exactly why the Karrat Foundation partnered with WinVote.io — a purpose-built tool designed to give control, transparency, customization and long-term sustainability without vendor lock-in or unknown costs.

What We’re Exploring to Help

We hear you and we’re actively looking at ways to reduce the delay while maintaining the integrity of the process. This includes:

  • Paying for expedited security audits to reduce downtime between development and deployment
  • Bringing on additional engineering resources to accelerate contract and backend work
  • Exploring a temporary pause or reduction in existing Security Council members compensation during the extended election preparation period. This is pending review from the Foundation’s legal team

These steps are under active discussion and will be communicated transparently as progress is made.

We believe that using WinVote for all governance actions, including elections, ensures long-term alignment, lower maintenance overhead, and a better experience for the KARRATco.

We encourage ongoing discussion, and we remain committed to working in the best interest of the community.

Thanks again for being engaged and thoughtful.

Sincerely,

The Karrat Foundation

4

The Security Council election has been in the Karratco Constitution since day one. On top of that, Webslinger — who manages this and many other Foundation DAOs — has experience running these exact same elections across multiple projects.

So why, at Karrat DAO, did the team wait until the last minute to begin preparing? This should have been a priority months ago.

Part of the Security Council’s responsibility is to uphold the Karratco Constitution. Not being ready by the clearly stated April 15th election date is a failure to meet the duties they agreed to when they took the role.

This delay feel more intentional than, a technical hurdle.

Cost and Platform Excuses Miss the Point

Saying Tally is costly or slow isn’t a strong defense when the DAO:

  • Never put a vote forward on what election platform to use,
  • Never informed the community early enough to weigh in,
  • Is now making community members pay the price for internal inaction.

The real issue is prioritization. You pushed a KIP to delay the election — but not one earlier to select or implement an election platform. That tells the story.

What should happen now is simple:
Use Tally for this election (push election out a month), and build out WinVote for the next one.

Plenty of DAOs already use Tally for their elections, it’s a proven solution. We might need to upgrade our subscription, sure, but that’s a far better outcome than completely disregarding the KARRATco Constitution just to give the current Council an extra 6 months in power after they failed to deliver on their responsibilities.

Let’s not forget, the Security Council is “responsible for upholding the KARRATco Constitution.”
Delaying this election violates that responsibility, plain and simple