KAMIYO Governance: Community-Driven Protocol Decisions
How KAMIYO token holders govern the protocol. Proposal creation, voting mechanisms, parameter changes, and the governance lifecycle.
Decentralized Governance for a Trust Protocol
A protocol that governs trust cannot itself be governed by a single entity. If one organization controlled the fee structures, oracle requirements, and dispute resolution rules, the entire system would be only as trustworthy as that organization. KAMIYO's kamiyo-governance program ensures that protocol decisions are made collectively by token holders through on-chain proposals and voting.
Governance is not a peripheral feature of KAMIYO — it is foundational. Every configurable parameter in the protocol, from escrow fees to oracle panel sizes to slashing penalties, is ultimately controlled by governance. This ensures the protocol evolves according to the collective judgment of its stakeholders rather than the preferences of any development team.
Governance Lifecycle
Proposal Creation
Any token holder who meets the minimum proposal threshold (a governance-controlled parameter) can create a proposal. Proposals specify the exact on-chain changes to be executed if approved — fee percentage updates, parameter modifications, program upgrade authorities, or treasury disbursements. The proposal instruction stores the full execution payload on-chain, ensuring transparency about exactly what each proposal would do.
// Create a governance proposal (requires 1M KAMIYO token balance)
await program.methods.createProposal(
'Reduce dispute resolution fee to 1.5%',
descriptionHash,
executionPayload,
).rpc();
// Vote on a proposal (voting power = token balance × staking multiplier)
await program.methods.castVote(proposalId, { for: {} }).rpc();
// Finalize after voting period ends
await program.methods.finalizeProposal(proposalId).rpc();Discussion Period
After creation, proposals enter a discussion period (default: 48 hours) during which no voting occurs. This gives the community time to analyze the proposal, debate its merits, and prepare their positions. During this window, the proposer can cancel the proposal if community feedback reveals flaws.
Voting Period
The voting period (default: 3 days) opens after the discussion window. Token holders vote by calling the castVote instruction with their choice: for, against, or abstain. Voting power is calculated from the voter's KAMIYO token balance multiplied by their staking duration multiplier (1x–2x). This ensures that long-term committed participants have proportionally more influence.
Votes are public (unlike oracle dispute votes), since governance decisions benefit from transparency and open debate rather than independence. There is no commit-reveal phase for governance votes.
Quorum and Approval
For a proposal to pass, two conditions must be met. First, the total voting power of all votes (for, against, and abstain) must exceed the quorum threshold — a minimum percentage of total staked supply that must participate. Second, the "for" votes must exceed the approval threshold as a percentage of non-abstain votes. Both thresholds are governance-controlled parameters.
Quorum Threshold
Default: 5 million KAMIYO tokens (0.5% of supply). Ensures that proposals cannot pass with only a handful of voters. Creating a proposal requires holding at least 1 million KAMIYO tokens.
Approval Threshold
Default: 66% of non-abstain votes (6,600 basis points). Requires a supermajority, ensuring strong consensus for any protocol change.
Timelock and Execution
Approved proposals do not execute immediately. They enter a timelock period (default: 24 hours) during which the community can review the upcoming change and prepare. After the timelock expires, anyone can call the executeProposal instruction to apply the changes. If no one executes within the execution window (default: 7 days), the proposal expires.
What Governance Controls
KAMIYO governance has authority over a comprehensive set of protocol parameters organized into several categories.
- Economic Parameters: Protocol fees on escrow settlement, dispute resolution fees, minimum stake requirements for oracle qualification, and staking reward distribution rates.
- Oracle Configuration: Oracle registration requirements, score deviation thresholds, commit and reveal window durations, and minimum oracle counts per escrow tier.
- Dispute Resolution: Evidence window duration, maximum dispute duration, resolution fee percentages, and slashing penalty amounts.
- Governance Meta-Parameters: The governance system can modify its own parameters — proposal thresholds, discussion periods, quorum requirements, and timelock durations. This self-referential capability ensures governance itself can evolve.
- Program Upgrades: Governance holds the upgrade authority for all KAMIYO programs. Program upgrades require elevated quorum and supermajority approval, ensuring they reflect broad community consensus.
Fast Voting with Ephemeral Rollups
For time-sensitive governance decisions, KAMIYO includes a kamiyo-fast-voting program that leverages MagicBlock's Private Ephemeral Rollups. This enables sub-50ms voting in a TEE (Trusted Execution Environment) with results settled back to Solana mainnet. Ephemeral rollups provide the speed of off-chain voting with the finality guarantees of on-chain settlement.
Fast voting is designed for operational decisions that need rapid turnaround — parameter adjustments, oracle configuration changes, and other routine governance actions where a 3-day voting period is unnecessarily slow.
Emergency Actions
In rare situations — such as a discovered vulnerability or an ongoing exploit — the standard governance timeline (discussion, voting, timelock) may be too slow. KAMIYO includes pauseGovernance and unpauseGovernance functions that allow the protocol admin to immediately halt governance operations. The staking program similarly supports pausePool and unpausePool for emergency staking freezes.
Emergency pause capabilities are limited in scope — they cannot upgrade programs, modify parameters, or move funds. They can only freeze and unfreeze specific program functions to prevent further damage while the community coordinates a response through the standard governance process.
Governance and the Trust Model
Governance is deeply integrated with the rest of KAMIYO's trust infrastructure. Governance voters must be stakers (economic commitment). Proposal outcomes are recorded as trust events by the trust layer engine. Governance participation contributes to Meishi reputation scores. And governance decisions directly affect the parameters that govern escrow, oracle voting, and dispute resolution. This circularity is by design: trust governs trust.
Frequently Asked Questions
How does KAMIYO governance work?
KAMIYO token holders can create proposals (requires 1M KAMIYO), vote on protocol changes, and influence fee structures, oracle parameters, and dispute resolution rules. Voting power is calculated from token balance multiplied by staking duration multiplier (1x–2x). Approval requires 66% of non-abstain votes with a quorum of 5M KAMIYO.
What can governance change?
Governance controls protocol fee percentages, oracle panel sizes, minimum stake requirements, dispute resolution timeouts, and can approve upgrades to the protocol programs.
Who can create governance proposals?
Any KAMIYO token holder with at least 1 million KAMIYO tokens can create proposals. This threshold ensures proposals come from participants with economic alignment to the protocol's success.
Build with KAMIYO Protocol
Start integrating trust infrastructure into your AI agent applications.
